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Abstract 

This  dissertation  describes  the  development  of  methods  for  formally  representing  and  applying 
design  information  that  enables  user  determined  software  design  decisions  to  be  automatically  and  correctly 
applied  to  software  requirements  producing  a  software  design. 

Formal  methods  for  developing  software  use  mathematical  frameworks  to  specify,  develop  and 
verify  software  systems,  especially  safety  critical  systems  where  error  free  software  is  a  necessity.  A 
transformation  system  is  a  formal  method  that  refines  an  abstract  requirement  specification  into  a  concrete 
implementation  by  successively  adding  design  decisions  in  the  form  of  precisely  verified  design 
information.  Current  algebraic  representations  of  design  information  (specifications,  moiphisms,  and 
interpretations)  and  methods  for  applying  algebraic  specification  design  information  (diagram  refinement) 
cannot  correctly  represent  and  apply  higher-level  design  information. 

This  investigation  develops  iimovative  methods  for  constructing  and  refining  structured  algebraic 
requirement  specifications,  as  opposed  to  individual  specifications.  A  category  of  diagrams  and  diagram 
morphisms  is  developed  and  applied  to  algebraic  specifications  and  morphisms  that  enables  the  stmcture  of 
requirement  specifications  and  design  information  to  be  dealt  with  explicitly.  Parameterized  diagrams 
enable  large  requirement  specifications  to  be  built  using  a  parameter-passing  analogy  that  is  of  a  higher- 
level  of  abstraction  than  current  methods.  Diagram  interpretations  enable  structured  design  information  to 
be  correctly  represented  and  applied,  including  the  refinement  of  parameterized  diagrams  and  restmcturing 
refinements. 

The  developed  approach  enables  one  to  create  a  library  of  correctly  represented  software  design 
information.  Software  could  then  be  developed  directly  from  the  requirements  by  selecting  design  choices 
from  the  library  and  correctly  applying  the  underlying  design  information.  Such  a  transformation  system 
would  enable  correct-by-constmction  software  to  be  developed  rapidly  and  easily. 
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Formal  Representation  and  Application  of 
Software  Design  Information 

1  Introduction 

Formal  methods  for  developing  software  are  based  upon  mathematical  frameworks  that  enable 
software  developers  to  specify,  develop  and  verify  software  systems  in  a  systematic  rather  than  an  ad  hoc 
manner  [Win90].  They  can  be  used  to  specify  requirements,  designs  and  implementations  precisely,  as 
well  as  to  detect  ambiguities,  incompleteness  and  inconsistencies  within  and  between  these  specifications. 
They  can  further  tie  a  requirement  specification  directly  to  a  more  concrete  realization,  thus  ensuring  the 
implemented  program  actually  meets  the  requirements.  A  formally  developed  program  may  take  longer  to 
produce  initially,  but  it  should  contain  fewer  errors  and  thus  reduce  the  cost  and  time  to  validate. 

An  abstract  view  of  formal  software  development,  called  the  refinement  or  transformation 
approach  [BCG83],  is  depicted  in  Figure  1-1.  Informal  requirements  are  used  to  develop  a  detailed  initial 
formal  specification  that  is  then  validated  against  the  requirements.  The  initial  requirement  specification  is 
abstract  in  that  there  are  many  equally  valid  implementations  for  die  specification.  Design  information 
(architectural,  data  structure,  algoritibinic)  is  successively  added  to  the  formal  specifications  through  a 
sequence  of  refinements  that  faithfully  preserve  the  properties  of  the  prior  specifications.  Finally,  when 
enough  design  information  has  been  added,  the  final  formal  specification  can  be  encoded  in  the 
programming  language  of  the  developer’s  choice,  then  compiled  and  executed.  The  final  specification  (and 
its  encoding)  is  a  correct  by  construction  realization  of  the  initial  requirement  specification. 

In  a  sense,  the  development  of  a  refinement  system  is  a  logical  progression  from  the  development 
of  compilation  systems.  Compilation  systems  and  refinement  systems  both  transform  an  “abstract 
specification”  to  a  more  concrete  one.  Design  information  in  a  compilation  system  provides  the  knowledge 
of  how  to  use  the  instruction  set  of  a  computer  and  its  data  registers  to  implement  the  various  programming 
language  features  such  as  control  stmctures,  procedure  calls  and  parameter  passing.  A  compilation  system 
encodes  that  design  knowledge  implicitly  and  applies  it  automatically.  Although  improvements  are 
constantly  being  made,  it  is  evident  that  compilation  systems  encode  and  apply  design  information  in  a 
manner  that  is  good  enough  for  most  programming  efforts. 
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Figure  1-1.  Formal  software  development  -  The  refinement  paradigm 


Unfortunately,  it  may  not  be  practical  (or  possible)  to  hardwire  specific  architecture,  data  structure 
and  algorithm  design  choices  into  a  refinement  system  in  a  similar  fashion  unless  the  domain  of 
applications  is  severely  restricted.  Instead,  it  may  be  possible  to  encode  a  variety  of  design  information  in  a 
library  so  that  a  software  developer  can  consciously  choose  what  designs  to  apply  to  a  specific  requirement 
specification.  Although  the  ultimate  goal  of  a  fully  automated,  general-purpose  refinement  system  may 
never  be  realized,  this  dissertation  aims  to  help  close  the  gap  between  compilation  systems  and  refinement 
systems,  as  formalization  must  precede  automation. 


LI  Background 

A  formal  software  development  system  should  be  able  to  represent  and  apply  design  information 
formally  and  not  just  be  able  to  represent  and  relate  a  requirement  specification  to  a  design  specification  in 
a  formal  manner.  Such  a  development  system  could  free  software  developers  from  having  to  develop  and 
encode  designs  from  first  principles,  as  design  decisions  could  be  selected  from  the  library  and 
automatically  applied  in  a  manner  that  ensures  their  correctness.  Without  such  a  library,  all  design 
decisions  that  transform  a  requirement  specification  to  a  design  specification  must  be  developed  and 
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applied  from  scratch.  (Each  refinement  step  must  be  manually  developed  and  individually  verified.)  With 
such  a  library,  the  design  information  is  encoded  and  verified  once  and  then  can  be  used  repeatedly  in  a 
manner  that  is  guaranteed  to  preserve  correctness. 

In  a  formal  transformation  system,  a  formal  representation  is  needed  for  the  requirement 
specification,  the  design  information,  and  the  result  of  applying  the  design  information  to  the  requirement 
specification.  These  formal  representations  and  the  application  of  design  information  to  requirement 
specifications  must  be  consistent  with  each  other.  This  dissertation  uses  algebraic  specifications  and 
specification  morphisms  [EMC092,  EM092,  Wir90]  for  representing  requirements  and  design  information. 
An  algebraic  specification  consists  of  a  set  of  sorts  (abstract  data  types),  a  set  of  operations  (abstract 
functions),  and  a  set  of  axioms  (logical  expressions  over  the  sorts  and  operations).  A  specification 
morphism  maps  the  signature  elements  of  a  source  specification  (the  sorts  and  operations)  to  those  in  a 
target  specification  such  that  the  translated  axioms  of  the  source  are  theorems  (logical  consequences)  of  the 
axioms  of  the  target. 

1,2  Limitations  of  Current  Techniques 

While  the  techniques  for  developing  refinements  (implementations)  of  simple  algebraic 
specifications  are  well  known  [EhR82,  San88,  Wir90,  and  BKL91],  these  techniques  do  not  scale  well  for 
larger  specifications.  Specifically,  stmctured  (aggregate)  specifications,  which  are  formed  by  combining 
many  smaller  component  specifications,  are  difficult  to  refine  because  of  the  sheer  number  of  sorts, 
operations,  and  axioms  in  the  aggregate  specification.  This  section  describes  in  general  terms  some  of  the 
problems  that  current  approaches  have  in  developing  and  refining  structured  specifications  that  the  research 
presented  in  this  dissertation  addresses. 

Constructing  structured  specifications 

While  the  requirements  of  a  small  problem  can  easily  be  specified  using  a  single  algebraic 
specification,  the  more  complex  requirements  of  a  larger  problem  may  necessitate  developing  an  aggregate 
specification  from  a  collection  of  smaller  component  specifications.  The  current  approaches  for  developing 
aggregate  specifications  are  too  low-level  for  developing  large  aggregates  or  are  based  on  parameterized 
specifications  whose  instantiation  does  not  retain  stmcture. 
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The  low-level  approach  for  developing  aggregate  specifications  essentially  lists  the  component 
specifications  and  their  relationships  with  each  other.  Each  component  specification  is  a  node  and  each 
relationship  is  an  arc  and  die  collection  of  node  and  arcs  form  a  diagram  that  represents  the  requirement 
structure.  The  diagram  of  components  can  then  be  used  to  form  the  aggregate  specification  by  collapsing 
all  of  that  structure  into  a  single  specification  that  essentially  contains  all  of  the  sorts,  operations  and 
axioms  of  the  component  specifications. 

An  example  of  a  diagram  consisting  of  20  nodes  (specifications)  and  20  arcs  (specification 
moiphisms)  is  depicted  in  Figure  1-2.  This  represents  the  data  structure  of  a  Petri  Net  [Pet77]  consisting  of 
a  set  of  places,  a  set  of  transitions,  a  bag  of  input  arcs  from  places  to  transitions,  a  bag  of  output  arcs  from 
transitions  to  places,  and  a  map  from  places  to  natural  numbers  representing  the  initial  marking  of  the  Petri 
Net.  Creating  such  a  diagram  structure  by  listing  its  dues  and  nodes  is  too  low-level,  error  prone,  and  non- 
intuitive. 


The  parameterized  specification  approach  for  developing  aggregate  specifications,  on  the  other 
hand,  iteratively  builds  up  the  final  specification  by  extending  a  specification  with  additional  signature 
elements  and  properties.  In  this  approach  a  higher  level  parameter  passing  syntax  is  used  to  instantiate 
parameterized  specifications  in  order  to  create  the  aggregate  specification.  The  overall  structure  is  never 
explicitly  realized  because  the  process  involves  adding  to  an  existing  specification  rather  then  creating  the 
structure  of  components.  Thus  in  the  parameterized  specification  approach,  while  it  may  be  easier  to 
develop  the  aggregate  specification,  the  structure  is  lost  by  the  construction  method. 
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Refining  structured  specifications 

Once  a  structured  requirement  specification  has  been  created,  the  problem  switches  to  refining  the 
structured  specification.  This  can  be  accomplished  by  refining  the  component  specifications  in  a 
compatible  way  and  then  combining  the  individual  refinements  of  the  con^onents  into  an  aggregate 
refinement  of  the  aggregate  specification. 

Unfortunately  such  an  approach,  called  diagram  refinement  [SJ95],  does  not  adequately  take 
advantage  of  the  structure  of  the  specification  as  at  heart  only  single  specifications  are  being  refined. 
Structure  is  used  only  to  aggregate  the  individual  specification  refinements  to  form  a  refinement  of  the 
aggregate  specification.  Thus,  for  exartqjle,  several  specifications  in  the  diagram  in  Figure  1-2  could  not  be 
refined  as  a  unit  using  diagram  refinement.  This  limits  the  type  of  design  choices  that  can  be  made  based 
on  the  initial  requirement  specification.  While  any  individual  specification  may  be  fi:ee  of  implementation 
bias,  the  structure  of  a  requirement  specification  contains  a  form  of  implementation  bias  when  the  diagram 
refinement  approach  is  used. 

L3  Problem 

This  investigation  is  concerned  with  making  it  easier  to  develop  and  refine  a  structured 
requirement  specification  using  algebraic  specification  methods.  The  goal  of  the  research  is  to  develop 
methods  for  formal  representation  and  application  of  high-level  design  information.  The  structure  of 
aggregate  specifications  is  to  be  retained  during  development  so  that  it  can  be  used  to  guide  refinements. 
Design  information  is  also  structured  and  (after  being  applied  to  a  requirement  specification)  that  stmcture 
is  retained  in  the  requirement  specification.  This  enables  refinements  to  substantially  revise  the  structure  of 
the  requirements  as  well  as  simply  adding  design  details. 

L4  Approach 

The  goal  of  the  dissertation  research  was  to  develop  methods  that  enable  higher-level  design 
information  to  be  formally  represented  and  applied.  The  approach  taken  is  to  consider  diagrams  of 
specifications  and  morphisms  as  the  primary  means  of  representing  requirement  information  and  design 
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information.  A  diagram  can  represent  both  the  content  and  the  structure  of  the  requirement  and  design 
information. 

In  order  to  accomplish  the  goal,  a  general  theory  of  diagrams  (independent  of  specifications  and 
specification  morphisms)  is  developed  using  category  theory,  which  enables  diagrams  of  nodes  and  arcs  to 
be  related  to  each  other  (via  diagram  morphisms)  in  a  way  that  preserves  both  the  structure  and  the  content 
of  the  source  diagram  in  the  target  diagram.  The  theory  enables  diagrams  of  specifications  to  be 
parameterized  and  instantiated  where  the  result  is  a  diagram,  not  a  single  specification.  Thus  it  is  the 
diagrams  of  specifications  and  specification  morphisms  that  are  created,  extended,  parameterized,  and 
instantiated,  not  individual  specifications.  This  approach  is  similar  to  the  low-level  diagram  construction 
methodology  in  that  the  result  of  extension  and  instantiation  is  a  diagram  and  not  a  specification.  It  is  also 
similar  to  the  parameterized  specification  approach  in  that  a  higher-level  parameter  passing  syntax  can  be 
used  to  constmct  the  diagram.  This  general  diagram  theory,  when  applied  to  specifications,  forms  the  basis 
of  the  specification  construction  and  refinement  methodology  developed  in  this  dissertation. 

Refinement  is  based  on  a  diagram  of  specifications  and  morphisms  instead  of  individual 
specifications.  This  added  structure  enables  the  refinement  mechanism  to  take  advantage  of  existing 
structure  in  a  given  requirement  specification  and  enables  restructuring  refinements  where  the  structure  of 
the  design  specification  differs  appreciably  from  the  structure  of  the  requirement  specification. 

The  design  information  is  itself  represented  by  a  diagram  of  specifications  and  morphisms.  A 
relationship  between  the  design  information  and  the  requirement  specification  is  established  that  maps  both 
the  structure  and  the  content  of  the  design  information  to  the  requirement  specification.  This  relationship  is 
then  used  to  merge  the  design  information  with  the  requirement  specification  in  order  to  create  a  more 
concrete  design  specification. 

L5  Limitations 

The  design  information  addressed  in  this  dissertation  is  of  the  data  structure  variety  only. 

Although  the  techniques  can  also  be  used  to  apply  algorithm  information,  the  representation  and  application 
of  such  design  information  are  not  addressed.  Additionally,  while  the  syntax  and  semantics  are  defined  for 
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some  of  the  language  constructs  developed  in  this  dissertation,  an  automated  tool  has  not  been  built. 
Finally,  this  dissertation  also  does  not  address  the  transformation  of  a  design  specification  to  code. 

1.6  Contributions 

Contributions  of  this  research  include  the  following: 

■  A  general  theory  of  diagrams  and  the  structure-  and  content-preserving  diagram  morphisms 
between  diagrams  based  on  category  theory  (Chapter  3). 

■  A  collection  of  higher-level  operations  for  creating,  composing,  relating  and  manipulating 
diagrams  and  diagram  morphisms  (Chapter  3). 

■  A  category  of  diagrams  of  specifications  and  morphisms  that  enables  diagrams  of  specifications 
and  morphisms  to  be  treated  as  if  they  were  simple  specifications  and  which  can  be  used  to 
apply  the  semantics  of  specifications  and  specification  morphisms  to  diagrams  of  specifications 
and  specification  diagram  morphisms  (Chapter  4). 

■  A  theory  of  parameterization  for  diagrams  that  subsxunes  all  current  (category  theory  based) 
specification  parameterization  mechanisms  while  providing  new  capabilities  (Section  3.5, 
Section  4.2,  and  Chapter  5). 

■  A  higher-level  syntax  for  constructing  diagrams  based  on  parameterized  diagrams  and  their 
instantiation  (Chapter  5). 

■  A  method  for  representing  structured  design  information  that  enables  the  preconditions  for 
applying  the  design  information  to  be  stated  accurately  (Section  4.3  and  Chapter  6). 

■  A  higher-level  refinement  mechanism  based  on  structured  design  information  that  enables  the 
design  information  to  be  automatically  applied  in  a  correct  manner,  given  that  the  preconditions 
are  met  (Chapter  6). 

1. 7  Overview  of  Document 

The  body  of  the  dissertation  assumes  that  the  reader  is  familiar  with  the  terminology  and  notation 
of  algebraic  specification  and  refinement,  models  and  category  theory  that  are  used  throughout  the 
document.  Appendix  A  (Category  Theory),  Appendix  B  (Specifications  and  Models)  and  Appendix  C 


7 


(Specification  Development  and  Refinement)  are  included  as  a  service  to  the  reader  who  is  unfamiliar  with 
die  basic  terms  and  notations  of  category  theory,  algebraic  specification,  or  specification  refinement. 

The  remainder  of  this  document  is  organized  as  follows: 

■  Chapter  2  provides  some  background  material  and  describes  the  problems  that  current  methods 
have  with  constructing  and  refining  structured  specifications. 

■  Chapter  3  defines  a  general  theory  of  diagrams  and  diagram  morphisms  that  underlies  the  later 
chapters.  This  chapter  also  defines  the  colimit  operation  over  categories  as  well  as  the  abstract 
notion  of  a  parameterized  diagram. 

■  Chapter  4  applies  the  general  diagram  theory  developed  in  Chapter  3  to  the  category  of 
specifications  {Spec)  and  then  extends  the  theory  based  on  underlying  category  Spec, 
Specifically,  the  notion  of  parameterized  (specification)  diagrams  and  diagram  interpretations 
are  developed. 

■  Chapter  5  builds  on  the  dieory  of  parameterized  diagrams  by  defining  the  syntax  and  semantics 
of  a  diagram  statement  that  enables  diagrams  of  specifications  and  morphisms  to  created, 
extended,  parameterized  and  instantiated.  This  section  also  demonstrates  that  parameterized 
diagrams  subsume  the  other  forms  of  specification  parameterization  and  instantiation  presented 
in  Section  2.3. 

■  Chapter  6  defines  a  new  mechanism  for  representing  and  applying  structured  design 
information. 

■  Chapter  7  provides  a  summary  and  evaluation  of  the  work  done  and  highlights  the  contributions. 
It  also  gives  some  suggestions  for  future  work  in  this  area. 

■  Appendix  D  provides  an  example  of  the  diagram  construction  method  being  used  to  create  a 
large  diagram.  This  example  illustrates  that  the  diagram  construction  method  does  not  scale 
well. 

■  Appendix  E  describes  existing  parameterized  specification  research  in  greater  detail  than  is  done 
in  the  body  of  the  dissertation  (in  Section  2.3)  and  compares  it  with  the  parameterized  diagram 
developed  in  Section  4.2. 

■  Appendix  F  provides  tiie  code  for  the  example  diagram  interpretations  presented  in  Chapter  6. 
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2  Background 


This  chapter  describes  other  research  related  to  representing  and  applying  design  information.  The 
latter  sections  describe  the  specific  problems  with  creating  and  refining  large  structured  requirement 
specifications  that  other  approaches  have  and  that  this  dissertation  solves. 

This  chapter  is  structured  as  follows.  Section  2.1  analyzes  different  formal  methods  representing 
how  design  information  is  currently  represented  and  applied.  Section  2.2  informally  defines  the 
terminology  used  in  this  dissertation  and  provides  pointers  to  the  more  formal  definitions  of  these  terms  in 
the  appendices.  Section  2.3  describes  research  on  parameterized  specifications.  Section  2.4  describes 
research  on  developing  large  structured  specifications.  Section  2.5  describes  research  on  refining  large 
structured  diagrams. 

2J  Related  Work 

In  order  to  accomplish  the  goals  of  this  dissertation,  different  formal  methods  were  analyzed  to 
discover  how  design  information  is  represented  and  applied.  This  section  presents  an  informal  survey  of 
some  of  the  more  prominent  formal  software  development  methods  and  analyzes  them  based  on  the  design 
information  that  can  be  explicitly  expressed  and  applied  in  the  methodology.  Section  2.1.1  describes  the 
design  information  issues  that  form  the  basis  of  the  analysis,  Sections  2.1.2  through  2.1.5  present  the 
findings  based  on  an  informal  categorization  of  existing  formal  development  methods,  and  Section  2.1.6 
summarizes  the  findings. 

2.1.1  Design  information  issues 

There  are  several  classic  knowledge  engineering  issues  that  all  knowledge-based  systems  have. 
The  basic  issues  associated  widi  design  information  in  a  formal  transformation  system  are  smular.  These 
issues  are  listed  below  and  form  the  basis  of  the  analysis  of  the  different  formal  development  methods. 

■  What  is  the  design  information? 

■  How  is  it  represented? 

■  How  is  it  applied  to  solve  a  problem? 
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How  is  it  acquired  or  updated? 


There  are  many  different  types  of  software  design  information.  Software  architectures  are  very 
high-level  design  information  while  local  peephole-like  program  optimizations  are  very  low-level. 
Between  them  are  high-level  abstract  data  type  representation,  high-level  algorithm  design  representation, 
and  statement  or  expression  selection. 

In  many  cases  the  actual  higher-level  design  information  is  only  represented  implicitly  in  a  set  of 
lower-level  design  decisions.  For  example,  constructing  an  algorithm  is  done  implicitly  when  explicitly 
selecting  a  sequence  of  programming  language  statements.  The  concept  of  the  algorithm  does  not  exist 
except  as  an  emergent  property  of  the  combined  statement  selections.  The  algorithm  has  no  independent 
representation  and  it  must  be  re-derived  every  time  it  is  “applied”. 

Additionally,  the  design  information  that  makes  up  a  refinement  could  originate  in  a  rule-based 
knowledge  base,  a  catalog  of  design  theories,  be  preprogrammed  into  the  system  as  a  transformation,  or 
come  fi^om  the  designer’s  previous  experience  (no  explicit  representation).  A  refinement  system  may  be 
extensible  by  the  users  of  the  system  (it  is  obviously  extensible  by  the  developers  of  the  refinement  system 
itself)  so  that  application  developers  can  add  their  own  design  information,  or  the  refinement  system  may 
be  a  “take  it  or  leave  it”  black  box.  A  design  choice  that  transforms  the  requirement  specification  could 
range  from  the  trivial,  or  non-intuitive  (an  “imfold”  step)  to  the  important  and  critical  (selection  of  global 
search  vs.  generate  and  test).  A  particular  design  decision  could  be  applied  as  a  single  refinement,  or  it 
could  take  several  smaller  refinements  to  implement  a  design  decision,  none  of  which  are  particularly 
helpful  independently.  The  proof  that  design  information  can  be  (or  has  been)  applied  in  a  correct  manner 
may  range  from  very  formal,  to  rigorous,  to  informal.  Finally,  the  selection  of  a  particular  design  decision 
could  be  specified  by  the  designer  in  a  declarative  fashion,  selected  by  the  designer  from  a  list  of  available 
choices,  pulled  from  a  designer’s  experience,  or  automated  by  the  refinement  system  by  blindly  searching 
or  intelligently  covering  the  design  space. 

The  next  several  sections  describe  some  of  the  existing  approaches  to  the  refinement  paradigm 
with  a  special  emphasis  on  the  design  information  that  underlies  a  refinement  step  in  the  methodology. 
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2.1.2  Manual  refinement,  or  posit-prove 

In  manual  refinement,  a  design  specification  is  developed  by  hand  and  then  proved  to  be  a 
refinement  of  the  requirement  specification  that  preserves  the  desired  properties.  Depending  on  tibie  relative 
differences  between  the  two  specifications,  the  proof  may  be  simple  or  extremely  involved.  Software 
development  methodologies  that  use  the  posit-prove  approach  typically  use  one  or  more  generic  proof  tools 
(associated  with  the  specification  language  used  by  the  methodology)  that  can  be  used  to  help  the  designer 
prove  the  relationship  between  the  two  specifications.  Unfortunately,  automated  proof  tools  are  often  not 
up  to  the  task  for  these  systems  [San88].  Automated  proof  checkers  can  be  used  to  verify  manually 
developed  proofs,  but  they  are  also  not  as  general  as  one  would  like. 

The  appeal  of  the  posit-prove  approach  is  that  it  is  very  general.  The  software  developer  has  full 
control  over  the  design  information  being  added  to  the  requirement  specification  (subject  to  the  limitations 
imposed  by  the  problem  being  solved,  the  representation  capabilities  of  the  specification  language,  and  the 
complexity  of  the  proof).  Defining  a  process  for  developing  refinements  can  scope  the  general  “anything 
goes”  approach  down  and  provide  software  developers  with  a  framework  to  guide  their  efforts.  The 
following  simplified  steps  are  used  in  a  typical  VDM  (Vienna  Development  Method)  refinement  [San88], 
which  is  an  example  of  a  posit-prove  approach: 

■  Develop  a  specification  SP’  that  is  believed  to  be  a  refinement  of  specification  SP. 

■  Define  a  retrieve  function,  retr^  that  maps  data  values  in  SP’  to  those  in  SP,  one  for  each  data 
type. 

■  Prove  that  retr  is  a  total  function  and  surjective  (that  every  concrete  data  value  has  an  abstract 
value  and  every  abstract  value  has  a  concrete  representation). 

■  Identify  an  operation /’  in  SP’  for  each  operation /in  SP. 

■  Prove  that pre’-f{retr{  v’ ))  => pre-fX  v' )  for  all  concrete  values  of  v\  and  all  f,f  pairs. 

(Ensures  the  pre-conditions  of  each  concrete  operation,/',  are  equally  or  less  restrictive  than  the 
preconditions  of  the  associated  abstract  operation,/). 

Prove  that  pre-f  {retr(  v ' ))  AND  post-f '  (  v ',  w ' )  post-f  {retr{  v ' ),  retr{  w ' ))), 

where  w '  =/ '  ( v ' ),  for  all  concrete  values  of  v '  and  w  \  and  all/ / '  pairs.  (Ensures  the  results, 

w\  produced  by  each  concrete  operation,/',  imply  those  produced  by  the  associated  abstract 

operations,/). 
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This  well-defined  approach,  while  tedious,  has  been  used  for  a  number  of  practical  problems  in 
academic  settings  as  well  as  in  commercial  use  [CW96].  Several  specification  languages  and  research 
efforts  use  refinement  steps  similar  to  those  in  the  above  list.  The  most  well  known  are  Z  [Spi89],  VDM 
[Jon90],  and  RAISE  [NHWG89].  RAISE  (Rigorous  Approach  to  Industrial  Software  Engineering)  is  a 
second-generation  formal  development  system  built  on  the  foundations  of  VDM.  Z,  the  VDM  specification 
language  and  the  RAISE  specification  language  are  all  model-based  specification  languages  with  implicit 
or  explicit  notions  of  pre-  and  post-conditions.  VDM  and  RAISE  specification  languages  use  functions, 
relations  and  sets  to  build  models  of  the  system.  Z  models  are  based  on  set  theory  and  use  an  interesting 
schema  calculus  to  combine  and  relate  specifications.  Hayes  [Hay92]  compares  VDM  and  Z  refinement 
approaches  in  detail. 

The  posit-prove  method  does  not  encode  any  design  information  except  that  which  is  implicit  in 
the  manually  developed  specifications.  All  design  decisions  come  from  the  experience  of  the  developer, 
and  their  realization  in  a  specification  is  achieved  manually.  Design  knowledge  cannot  be  reused  or 
extended  in  the  manual  approach.  This  approach  can  be  applied  to  any  level  of  programming  problem. 

2.1.3  Transformation  synthesis 

In  a  transformation  system,  a  transformation  takes  as  input  a  specification,  SP  (or  part  of  a 
specification),  and  returns  a  second  specification,  SP’,  with  the  appropriate  design  information  added.  A 
transformation  is  typically  a  syntactic  manipulation  of  the  specification.  Individual  transformations  can  be 
applied  automatically  using  some  set  of  rules  or  built-in  knowledge  base,  or  a  designer  can  selectively 
choose  which  transforms  to  apply  depending  on  which  design  choices  are  made.  Each  transformation 
comes  with  an  associated  proof  obligation  that  ensures  that  the  transformation  can  be  (or  has  been)  applied 
correctly.  Many  different  refinement  systems  use  the  transformation  synthesis  approach.  These  systems 
have  been  loosely  categorized  in  this  dissertation  into  the  following  four  basic  approaches:  catalog  rule- 
based,  encoded  mle-based,  generative  rule-based  and  refinement  calculus-based. 

A  catalog  mle-based  refinement  approach  encodes  the  design  knowledge  in  a  library  of  mles  fliat 
can  be  applied  to  a  specification  SP  in  order  to  transform  it  into  SP’.  The  transformation  mles  often  have 
the  following  form.*  If  (a  part  of)  SP  matches  pattern  PI  then  modify  (a  part  of)  SP  so  that  it  matches 
pattern  P2.  Catalog  mles  can  often  be  extended  and  modified.  Like  all  knowledge  bases,  it  is  difficult  to 
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come  up  with  a  complete  and  consistent  set  of  rules.  Catalog  rule-based  transformation  systems  are  often 
applied  automatically,  and  the  design  space  is  restricted  to  the  available  rules  and  their  mode  of  application. 
(In  automated  systems,  some  rules  and  design  spaces  may  never  be  selected  based  upon  other  rules  always 
being  selected  first).  Catalog  rule-based  systems,  despite  their  syntactic  nature,  tend  to  be  less  formal  and 
more  heuristically  oriented  than  other  approaches.  It  can  be  difficult  to  determine  precise  proof 
requirements  for  mdre  complex,  design  rich  mles. 

In  an  encoded  rule-based  approach,  the  design  knowledge  is  encoded  as  an  algorithmic  procedure 
that  can  be  applied  to  SP  to  obtain  SP’.  These  encoded  mles  can  be  more  powerfiil  than  catalog-based 
mles  as  they  can  perform  transformations  that  are  more  global  in  nature.  In  one  sense,  the  encoded  mle- 
based  approach  subsumes  the  catalog  mle-based  approach  as  any  mle  that  can  be  represented  and  applied 
in  an  open  and  extensible  library  catalog  system  could  be  encoded  and  applied  using  a  closed,  procedural 
method  (encoded  mle-based  approach).  The  encoded  mle-based  approach  is  also  often  less  formal  for  the 
same  reasons  as  the  catalog  mle-based  approach.  Encoded  mles  can  be  applied  automatically  or  manually. 
Users  of  the  transformation  system  cannot  extend  the  encoded  mles  however.  AFIT  tool  [HB94],  and  CIP 
[Par90]  are  examples  of  encoded  mle  systems. 

In  a  generative  mle-based  system,  there  are  only  a  few  simple,  general  mles  that  cover  all  possible 
transformations  of  interest  to  the  refinement  system.  Burstall  and  Darlington  [BD77]  describe  a  set  of 
seven  simple  mles  (fold,  unfold,  introduce  a  function  or  variable,  rewrite  expression,  etc.)  that,  when 
applied  in  various  combinations,  can  transform  simple  algorithms  into  more  complex  and  efficient  ones. 
Later  work  on  a  generative  mle  set  that  does  a  better  job  of  preserving  equivalence  between 
transformations  than  does  the  fold/unfold  mle  was  accomplished  by  Sherlis  [SchSl].  The  mles  can  be 
applied  manually,  via  a  (mostly)  blind  search,  or  via  an  informal  design  tactic.  The  generative  mle-based 
approach  is  a  special  case  of  the  encoded  transformation  approach  where  the  number  of  transformations  is 
severely  restricted  and  each  transformation  is  formally  and  precisely  defined  in  terms  of  its  effects  and  its 
proof  obligations.  Because  of  this,  design  information  cannot  be  represented  and  applied  by  a  single 
refinement  step  but  is  instead  emergent  from  a  sequence  of  refinement  steps  involving  the  smaller 
transforms. 
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The  refinement  calculus  is  an  extension  of  the  Guarded  Command  Language  [Dij76],  in  which  a 
pre-order  relation  is  established  for  some  program  fragments  that  indicates  which  program  fragments  can 
be  replaced  by  others.  The  refinement  calculus  was  developed  independently  by  several  different 
researchers  [Bac88,  Mor90].  While  this  transformation  approach  does  have  a  syntactic  component,  the 
preorder  relationship  is  defined  in  terms  of  weakest  precondition.  Thus,  the  rules  of  the  refinement 
calculus  express  transformations  in  which  a  program  fragment  can  be  substituted  for  another  when  the 
weakest  precondition  of  one  implies  the  weakest  precondition  of  the  other.  Various  laws  in  the  refinement 
calculus  are:  strengthen  post  condition,  weaken  precondition,  introduce  assignment  (or  sequential 
composition,  conditional,  loop,  or  local  block),  and  introduce  or  eliminate  logical  constants.  Typically  a 
software  synthesis  task  in  the  refinement  calculus  starts  with  a  single  specification  statement,  contains 
many  intermediate  steps  in  which  the  “specification”  consist  of  mixed  specification  statements  and  guarded 
command  code,  and  ends  up  with  a  “specification”  containing  only  guarded  command  statements.  The 
laws  serve  to  manipulate  the  specification  statements  (modifying,  adding  and  removing  them)  and  to 
introduce  guarded  command  statements.  As  the  refinement  proceeds  by  using  and  applying  the  various 
laws,  the  individual  design  steps  introduce  individual  guarded  command  statements  that  collectively  ensure 
the  post  condition  given  input  satisfying  the  weakest  precondition.  The  rules  can  be  applied  manually,  via 
a  (mostly)  blind  search,  or  via  an  informal  design  tactic.  As  in  the  generative  mle-based  approach,  the 
individual  laws  in  the  refinement  calculus  approach  are  formally  defined  and  have  precise  proof  obligations 
related  to  their  use.  The  design  information  in  the  refinement  calculus  approach  is  of  a  higher  level  than 
the  generative  rules,  but  they  are  still  on  the  level  of  individual  statements,  not  algorithms  or  data 
structures. 

Transformation  systems,  including  examples  of  many  of  the  above  approaches,  were  surveyed  by 
Partsch  and  Steinbniggen  [PS83]  in  1983.  A  comparative  study  of  different  algorithm  synthesis  methods 
[SA89]  surveyed  22  different  published  algorithm  derivations  spread  over  7  different  problems  (insertion 
sort,  N-queens,  graph  marking,  convex  hull,  etc)  using  transformation  approaches.  In  that  study  only  about 
30%  of  the  published  derivations  were  partially  or  completely  developed  by  implemented  transformation 
systems. 
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The  transformation  synthesis  approach  does  not  encode  high-level  design  information  very  well, 
and  only  some  of  the  approaches  encode  low-level  design  information  explicitly.  In  the  generative  and 
refinement  calculus  approaches,  the  refinement  rules  reflect  program  transformations  that  rarely  reflect  an 
individual  design  decision  other  than  the  use  of  a  particular  statement.  A  series  of  transformations  in  the 
generative  and  refinement  calculus  approaches  do  reflect  the  design  decisions,  but  that  higher-level 
information  is  implicit  and  difficult  to  represent  and  apply  mechanically.  Thus,  the  implementation  of  a 
design  decision  using  these  two  approaches  cannot  be  reused  in  successive  development  efforts,  but  must 
be  re-proved  each  time.  Because  of  this  limitation,  these  two  approaches  are  used  in  a  “search”  fashion  that 
is  only  effective  for  small  problems  or  used  to  make  specific  spot  improvements  to  algorithms  and  designs. 
Feather  [Fea82]  mitigated  this  problem  somewhat  with  his  research  that  used  a  pattern  of  the  overall  form 
of  the  desired  result  to  trim  the  search  space  when  the  generative  mles  were  applied  automatically. 

The  catalog  and  encoded-mle  approaches  to  transformation  synthesis  can  encode  limited  higher- 
level  design  information.  The  more  complex  the  design  information,  though,  the  more  complex  the  rule 
and  the  fewer  cases  to  which  it  can  be  applied.  Often  in  order  to  use  a  complex  rule  a  specification  must 
first  be  “jittered”  into  a  particular  form.  The  syntactic  form  of  the  rules  limits  the  catalog  approach  to 
design  information  that  can  be  applied  using  pattern  matching.  The  encoded  approach  can  in  theory  encode 
any  type  of  design  information;  it  is  limited  in  that  it  cannot  be  extended  easily  and  that  it  may  be  difficult 
to  jitter  a  specification  into  the  proper  form.  Because  of  the  limited  abilities  in  terms  of  encoding  design 
information,  the  transformation  approach  is  useful  mostly  for  refining  existing  designs  or  for  developing 
lower-level  implementations  and  specific  algorithms.  The  developer  must  know  which  set  of 
transformations  to  apply  to  accomplish  a  particular  design  decision,  or  the  system  can  blindly  search  for  an 
appropriate  set  of  transformations,  or  systematically  search  using  a  desired  goal  or  a  design  tactic. 

2. 1 .4  Deductive  synthesis 

In  the  deductive  synthesis  approach,  a  program  and  its  proof  are  developed  in  parallel,  with  the 
proof  prescribing  the  program.  First,  a  specification  is  translated  into  a  theorem  that  contains  a  relationship 
stating  the  existence  of  the  output  variables  given  the  input  variables.  Next,  the  theorem  is  proved  in  a 
constructive  fashion.  Finally,  a  program  is  extracted  from  the  proof  of  the  theorem. 
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When  the  existence  proof  of  a  program  output  is  done  in  a  constructive  fashion,  there  exists  an 
associated  computational  method  for  finding  that  output.  In  fact,  as  the  theorem  is  being  proved,  the 
program  is  being  built  up.  The  proof  techniques  that  are  being  used  can  be  directly  associated  with 
programming  constructs.  For  example,  when  the  proof  uses  case  analysis,  mathematical  induction  and 
lemmas,  the  program  uses  conditionals  (case,  if-then-else),  recursion  (iteration)  and  procedures, 
respectively.  As  an  example,  a  specification  for  sorting  a  list,  sort(Z),  has  “TRUE”  as  a  precondition  and 
“Permutation(Z,^)  a  ordered(5^)”  as  a  post  condition.  A  theorem  of  that  specification  is 
“V  L,3s\  permutation(Z,5)  a  ordered(5)”.  Proving  constructively  that  for  all  lists  L,  there  exists  a  list  s  that 
is  an  ordered  permutation  of  list  L  will  also  provide  a  computational  method  for  finding  such  an  ordered 
list.  Different  choices  in  the  use  and  order  of  proof  techniques  result  in  different  algorithmic 
implementations.  The  resultant  program  is  guaranteed  to  be  correct  because  the  program  and  the  proof  of 
its  correctness  are  developed  in  concert. 

Examples  of  deductive  proof  systems  include  the  Deductive  Tableau  Framework  [MW92]  and 
Nuprl  [Con86].  The  Deductive  Tableau  Framework  for  program  synthesis  has  been  implemented  for  at 
least  three  different  logics  and  theorem  provers  [Wal97].  The  Nuprl  system  for  deductive  synthesis  is 
based  upon  a  constmctive  logic  developed  by  Martin-Lif  [Mar82].  In  both  cases,  the  resultant  program  is 
typical  of  automatically  generated  program  code  in  that  it  must  be  refined  and  optimized  further  to  remove 
simplistic  implementation  choices. 

The  deductive  synthesis  refinement  approach  encodes  design  knowledge  indirectly  as  proof 
techniques.  By  choosing  a  particular  proof  technique,  the  theorem  prover  is  implicitly  choosing  a  design 
refinement  in  the  eventual  program.  Hiese  design  refinements  are  probably  unlike  the  design  refinements 
of  the  other  approaches.  The  deductive  synthesis  approach  appears  similar  in  power  to  the  generative  mle 
approach  and  refinement  calculus  approach  described  above.  Like  these  other  methods,  the  design 
information  implicit  in  the  deductive  synthesis  approach  must  be  re-proven  each  time.  Because  there  are 
no  proof  techniques  related  to  higher-level  design  decisions,  this  approach  is  limited  to  smaller  problems 
where  the  proof  development  is  manageable. 
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2.1.5  Classification  synthesis 

When  performing  classification  synthesis,  a  specification  is  related  to  a  design  theory  in  a  way  that 
classifies  it  as  an  instance  of  the  problem  solved  by  the  design  theory.  If  a  specification  has  certain 
properties  identified  by  the  design  theory,  then  the  specification  and  design  theory  can  be  combined,  which 
adds  design  information  to  the  specification.  In  some  cases  the  design  theory  may  have  to  be  extended  in 
order  to  match  up  with  the  application  specification.  In  other  cases  the  requirement  specification  must  be 
extended  in  order  to  meet  the  needs  of  the  design  theory.  When  refining  data  types,  for  exanple,  sets  can 
be  mapped  to  Usts  in  a  way  that  duplicates  the  properties  of  the  set  abstract  data  type  using  a  list  abstract 
data  type.  That  is  to  say  a  Set  ADT  is  interpreted  as  a  List  ADT  that  has  been  extended  with  additional  set¬ 
like  operations  and  behavior  in  order  to  implement  the  Set  ADT.  Any  requirement  specification  that  has  a 
set  in  it  can  be  combined  with  the  set-as-list  design  information  to  indicate  that  the  abstract  Set  of  values  is 
to  be  implemented  by  a  list  data  structure.  Other  design  decisions  for  implementing  a  set  could  be  as  an 
array,  as  a  bit  vector,  as  a  tree,  as  a  recognizer  function,  etc.  If  the  implementation  programming  language 
has  lists  as  an  intrinsic  data  type,  as  does  the  programming  language  Lisp,  then  this  aspect  of  the 
requirement  specification  need  not  be  refined  further.  However,  if  the  implementation  language  has 
pointers  (reference  types)  and  record  types  then  a  list  ADT  can  be  further  refined  as  a  luiked-list.  These 
design  choices  could  be  combined  prior  to  their  application. 

When  a  design  choice  involves  an  algorithm,  an  operation  in  the  requirement  specification  is 
mapped  to  some  algorithm  scheme  (global  search,  divide  and  conquer,  etc)  that  can  be  used  to  implement 
the  operation.  The  mapping  associates  input  and  output  types  of  the  requirement  specification  operation  to 
types  in  the  algorithm  theory.  The  algorithm  scheme  may  require  operations  such  as  destructors  and 
constructors  for  the  data  types  to  be  mapped  as  well.  These  must  be  supplied  before  the  algorithm  theory 
can  be  combined  with  the  operation  in  the  requirement  specification.  Combining  the  algorithm  theory  with 
the  specification  operation  constitutes  a  refinement  step  and  design  decision  that  implements  the  operation 
using  the  specified  algorithm. 

When  accomplished  by  a  refinement  system,  the  design  schemes  may  be  hard-coded  into  the 
system  or  may  be  part  of  a  knowledge  base.  An  automated  synthesis  system  may  have  preprogrammed  into 
it  the  necessary  steps  to  instantiate  the  parameterized  design  scheme.  This  parameter  information  can  be 
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selected  from  a  predetermined  list  provided  by  the  system  or  from  a  list  specifically  constructed  based  on 
the  mapping  from  the  problem  to  the  algorithm  scheme,  or  previously  entered  parameter  information. 
Sometimes  the  needed  parameter  can  be  constructed  automatically  based  on  previous  information. 
Examples  of  classification  synthesis  include  the  Data  Type  REfinement  system  (DTRE)  [BG91],  the 
Kestrel  Interactive  Development  System  (KIDS)  [Smi90a,  Smi90b],  Planware  [Smi97],  and  Specware 
[WSGJ96]. 

The  DTRE  system  performs  data  type  refinements.  A  specification  using  abstract  data  types  (sets, 
sequences,  finite  maps  and  tuples)  is  mapped  to  a  specification  with  concrete  data  types  (lists,  bit-vectors, 
and  array-based).  The  developer  supplies  some  implementation  directives,  and  DTRE  completes  the  job  by 
selecting  the  most  efficient  implementation  based  on  those  directives.  The  implemented  system  is  then 
optimized  based  on  the  set  of  operations  used  as  well  as  data  flow  analysis.  The  mappings  from  abstract  to 
concrete  types  represent  the  design  information,  but  imfortunately  they  are  pre-built  into  the  system  and 
cannot  be  changed  or  added  to  by  the  developer.  Additionally,  the  refinements  are  all  of  the  type 

Data-type  Data-type. 

More  complex  data  type  restructuring  involving  multiple  data  types  is  not  dealt  with. 

The  KIDS  system  is  designed  for  performing  algorithm  refinements.  The  developer  creates  a 
domain  theory  (an  involved  process)  and  then  specifies  a  problem  in  terms  of  the  domain  theory.  The 
problem  must  be  written  in  the  DRJO  format  (Domain  type.  Range  type.  Input  predicate.  Output  predicate), 
where  an  element  of  the  Domain  type  satisfying  the  Input  predicate  results  in  an  element  of  the  Range  type 
satisfying  the  Output  predicate.  Based  on  the  D  and  R  portions  of  the  problem  to  be  solved  the  KIDS 
system  offers  a  list  of  design  tactics  that  may  be  suitable  for  solving  the  problem.  A  design  tactic  may  have 
associated  with  it  one  or  more  algorithm  and  program  schemes.  After  making  choices  the  developer  is 
prompted  to  fill  in  the  parameterized  algorithm  and  program  schemes  when  necessary.  The  developer, 
using  a  number  of  transformation  techniques  (local  optimizations,  partial  evaluation,  finite  differencing, 
etc.)  can  then  optimize  the  resulting  generated  program  code.  The  result  is  a  function  that,  when  given  an 
element  of  type  D  satisfying  precondition  I,  returns  an  element  of  type  R  satisfying  post-condition  O.  The 
design  information  that  KIDS  uses  is  in  the  form  of  algorithm  and  program  schemes,  and  the  knowledge 
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necessary  to  instantiate  them.  Part  of  this  information  is  accessible  to  the  developers,  but  much  of  it  is 
hard-coded  into  the  system,  and  cannot  be  extended  or  modified. 

The  Specware  system  is  based  on  an  algebraic  specification  language  (sorts,  operations,  and 
predicate  logic  statements  over  the  sorts  and  operations)  that  uses  category  theory  concepts  such  as 
moiphisms,  interpretations,  colimits,  diagrams,  etc.,  to  construct  and  refine  specifications  [SJ95]. 

Individual  specifications  can  be  refined  via  an  interpretation  to  other  more  concrete  specifications.  Such  an 
interpretation  is  a  piece  of  design  information  that  may  be  generic  enough  to  be  applicable  in  a  variety  of 
situations.  Constructing  a  diagram  (a  structure)  of  specifications  and  morphisms  and  then  combining  the 
diagram  (via  a  colimit)  can  create  a  composite  specification.  If  each  individual  specification  in  the 
structure  has  a  refinement  tiiat  is  con^atible  with  the  other  refinements  then  a  refinement  of  the  composite 
specification  can  be  constracted  automatically.  The  Specware  system  can  represent  design  information  for 
data  type  and  algorithm  design  decisions  but  does  not  represent  lower  level  design  decisions  as  well. 

The  Planware  system  is  a  higher-level,  domain-specific  version  of  Specware  designed  to 
synthesize  scheduling  programs  [Smi97].  Input  to  die  system  is  accomplished  by  selecting  characteristics 
of  the  tasks  (release  time,  due  time,  quantity,  and  precedence,  etc)  and  resources  (consumable,  and  various 
forms  of  reusable)  of  some  scheduling  problem.  The  system  then  automatically  generates  a  scheduling 
program  via  the  same  methodology  used  in  KIDS  except  generalized  to  work  in  the  Specware  environment. 
The  range  of  available  data  structures  and  iiiq)lementation  algorithms  were  carefully  chosen  by  the 
synthesis  system  (actually  the  developers  of  die  synthesis  system)  to  be  extremely  efficient  for  the 
scheduling  domain.  While  the  general  form  of  the  data  structures  and  algorithms  are  programmed  into  the 
synthesis  system,  the  actual  data  structures  and  algorithms  are  created  based  upon  the  input  specifications 
and  problem  constraints.  The  design  information  in  Planware  can  be  applied  to  create  an  entire  family  of 
scheduling  applications  but  cannot  be  used  to  generate  other  types  of  programs. 

Each  of  the  systems  described  above  is  a  research  system  that  was  built  to  solve  realistic  problems. 
Only  die  Specware  system  can  be  extend  with  additional  design  information.  The  control  information  that 
manipulates  the  design  information  and  ensures  that  the  parameterized  information  is  correcdy  instantiated 
is  non-existent  in  the  Specware  system  and  is  hard-coded  in  the  others. 
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2. 1 .6  Summary  of  refinement  paradigms 

The  posit-prove  paradigm  has  the  greatest  generality  and  has  been  of  the  most  practical  use  in 
industry,  but  it  has  no  explicit  way  to  represent  the  higher-level  design  information.  Consequently, 
automated  support  for  the  refinement  process  comes  in  the  form  of  bookkeeping  support  and  proof  tools 
that  help  to  prove  the  correctness  of  manually  represented  and  applied  design  decisions. 

The  transformation  approach  has  four  variations:  catalog  rule-based,  encoded  rule-based, 
generative  rule-based  and  refinement  calculus  based.  The  catalog  rule  and  encoded  rule  transformation 
approaches  have  potentially  no  limit  to  the  design  information  they  can  represent  and  apply.  The  problem 
is,  the  more  complex  the  design  information,  the  more  complex  the  rule  and  the  fewer  situations  to  which  it 
can  be  applied.  The  catalog  rules  are  limited  in  that  they  are  inherently  S3fiitax  based.  Catalog  rules  are 
useful  for  finishing  touches,  like  peephole  optimization  in  a  compilation  system  and  are  often  automatically 
applied.  Encoded  rules  are  typically  less  formal  as  they  are  procedural  (read  operational)  in  nature  and  may 
not  be  proved  correct  over  the  domains  in  which  they  can  operate,  otherwise  they  tend  to  have  the  same 
benefits  and  problems  as  the  catalog  rules.  In  both  t5^es  of  mle-based  systems  it  is  expected  that  the  rules 
fire  without  much  jittering  and  so  they  are  limited  to  either  low  level  design  decisions  or  to  specialized 
niche  transformations. 

The  generative  rule-based  and  refinement  calculus-based  approaches  are  limited  in  the  type  of 
design  information  that  can  be  expressed.  In  their  purest  form,  they  are  manually  applied  and  all  design 
information  is  emergent  from  the  sequences  of  the  application  of  the  small  transformations.  There  are 
some  ways  to  package  sequences  of  steps  or  to  heuristically  guide  the  use  of  the  individual  transformation 
steps  that  enables  limited  higher-level  design  information  to  be  represented  and  applied.  In  addition, 
informal  design  tactics  and  approaches  can  be  developed  that  when  followed  can  help  guide  the  developer 
in  applying  the  rule  set. 

The  deductive  synthesis  approach  uses  proof  tactics  instead  of  design  information.  The  design 
information  is  one  step  removed  from  the  refinement  steps  (which  in  this  case  are  actually  proof  steps).  In 
this  approach,  like  the  generative  and  refinement  calculus  approaches,  the  design  information  is  implicit  in 
a  sequence  of  steps. 
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The  classification  synthesis  approach  can  represent  a  variety  of  design  information  at  a  much 
higher  level  than  the  other  refinement  approaches.  Examples  include  data  type  theories  (sets  as  bags, 
sequences,  arrays,  bit  vectors,  etc.  and  various  other  mappings),  algorithm  theories  (divide  and  conquer, 
global  search,  etc.),  and  application  domain  theories  (scheduling,  planning).  The  real  work  is  done  in 
advance  when  the  higher-level  design  information  is  abstracted,  generalized  and  proven  correct.  Applying 
the  design  information  requires  more  work  for  a  greater  gain,  as  a  larger  granularity  of  design  decisions  can 
be  made  with  the  classification  approach.  Unfortunately,  establishing  a  relationship  between  a  requirement 
specification  and  design  information  that  should  apply  to  it  may  be  arbitrarily  difficult.  The  key  to  making 
classification  synthesis  more  viable  is  increasing  the  ease  in  making  the  classification  to  begin  with.  In 
other  words,  increase  the  ability  for  design  information  and  (parts  of)  a  requirement  specification  to  be 
related,  and  increase  the  breadth  of  design  information  that  can  be  represented  and  applied. 

Of  those  systems  that  could  represent  and  apply  design  information  in  a  formal  manner,  one 
family  of  systems,  DTRE,  KIDS,  Planware  and  Specware  [SJ95,  SLM98],  stood  out  as  being  able  to 
represent  and  apply  high  level  data  structure  design  decisions  and  algorithm  design  decisions 
[Gra96,Smi90a,Smi97].  The  theory  underlying  the  representation  and  application  of  design  information  in 
this  family  of  systems  is  directly  exposed  in  the  Specware  system. 

The  Specware  language  can  be  viewed  as  being  analogous  to  an  assembly  level  programming 
language;  necessary  low  level  features  are  present  in  the  language,  but  few  higher-level  concepts  are 
present.  Although  many  other  specification  systems  use  die  concepts  of  specifications  and  specification 
morphisms,  the  Specware  system  in  particular  pioneered  the  concept  that  the  relationships  between 
specifications  are  as  important  as  the  specifications  themselves  and  used  them  to  provide  an  open  and 
extensible  framework  for  representing  and  applying  design  information.  In  theory,  all  of  the  design 
information  captured  by  the  DTRE,  KIDS,  and  Planware  systems  can  be  modeled  in  Specware.  In  practice, 
the  best  ways  to  represent  and  manipulate  design  information  in  an  algebraic  fi-amework  are  still  being 
developed  [Gra96].  Specifically  the  Specware  system  has  a  limited  notion  of  a  diagram  of  specifications 
and  morphisms  in  terms  of  being  able  to  construct,  manipulate  and  refine  them.  Construction  is  based  on 
listing  the  nodes  and  arcs  and  refinement  is  based  on  the  refinement  of  individual  specifications  instead  of  a 
larger  stracture. 
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2.2  Terminology 


This  section  briefly  and  informally  covers  some  of  the  terms  used  in  this  dissertation.  As  a  service 
to  the  reader,  each  term  is  formally  defined  in  the  associated  appendix  definition. 

2.2.1  Category  theory  terms 

A  category  (Definition  A.l)  is  a  mathematical  structure  consisting  of  a  collection  of  objects  and 
arrows  between  the  objects  where  each  object  has  an  identity  arrow,  all  successive  arrows  compose,  and  the 
composition  is  associative.  A  diagram  (Definition  A. 6)  is  a  select  collection  of  objects  and  arrows  of  a 
particular  category.  To  be  a  commutative  diagram  (Definition  A.7),  all  arrows  between  the  same  source 
and  target  objects  in  the  diagram  must  be  equivalent.  Arrows  within  a  category  can  be  isomorphic 
(Definition  A.8),  monomorphic  (Definition  A.9)  or  epimorphic  (Definition  A.  10)  depending  on  their 
relationship  with  other  arrows  in  the  category. 

K  functor  (Definition  A.l  1)  maps  the  objects  and  arrows  of  one  category  to  those  of  another  such 
that  identity  and  arrow  compositions  are  preserved.  A  category  can  have  subcategories  (Definition  A.  13) 
and  full  subcategories  (Definition  A.  14)  which  have  only  a  subset  of  the  parent  categories  objects  and 
arrows. 

A  cocone  (Definition  A.  16)  is  a  collection  of  arrows  from  a  diagram  to  another  object  where  the 
arrows  in  the  cocone  commute  when  composed  with  the  arrows  within  the  diagram.  A  colimit  (Definition 
A.  17)  is  a  minimal  target  object  of  a  cocone,  as  every  other  cocone  object  of  that  diagram  has  an  arrow  to  it 
from  the  minimal  cocone  object.  A  category  that  has  a  cocone  object  for  all  diagrams  is  termed  cocomplete 
(Definition  A.  18).  A  pushout  (Definition  A.  15)  is  a  specialization  of  a  colimit  over  a  particular  diagram 
form. 

2.2.2  Specification  and  Model  terms 

A  specification  (Definition  B.14)  contains  a  set  of  sorts  (abstract  data  types),  a  set  of  operations 
(abstract  function  headers),  and  a  set  of  axioms  over  the  sorts  and  operations.  A  specification  morphism 
(Definition  B.18)  maps  the  signature  elements  of  a  source  specification  to  those  of  a  target  specification 
such  that  the  (translated)  axioms  of  the  source  specification  are  theorems  of  the  target  specification. 
Specifications  and  specification  morphisms  are  the  objects  and  arrows  of  category  Spec  (Proposition  B.19). 
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A  model  of  a  specification  (Definition  B.34)  has  a  set  of  elements  (carrier  set)  for  each  sort  and  a 
function  for  each  operation  where  all  axioms  of  the  specification  are  satisfied  by  the  model.  All  models  of 
the  target  of  a  specification  morphism  can  be  reduced  by  the  extra  carrier  sets  and  functions  such  that  they 
are  models  of  the  source  specification  (Proposition  B.39). 

2.2.3  Specification  development  and  refinement  terms 

A  conservative  extension  morphism  (Definition  C.8)  is  one  in  which  any  model  of  the  source 
specification  can  be  extended  with  additional  carrier  sets  and  functions  so  that  it  is  a  model  of  the  target 
specification.  A  definitional  extension  morphism  (Definition  C.12)  is  one  in  which  that  model  extension  is 
uniquely  defined.  The  property  of  being  a  conservative  or  definitional  extension  morphism  reflects  across 
a  pushout  square  (Proposition  C.19). 

An  interpretation  (Definition  C.20)  is  a  morphism  fi:om  a  source  specification  to  a  definitional 
extension  (mediator)  of  a  target  morphism  that  indicates  how  a  model  of  the  target  specification  can  be 
extended  to  become  a  model  of  the  source  specification.  An  interpretation  morphism  (Definition  C.24) 
uses  specification  morphisms  to  link  the  source,  mediator  and  target  specifications  of  two  interpretations 
such  that  the  larger  Spec  diagram  commutes.  Interpretations  and  interpretation  morphisms  are  the  objects 
and  arrows  of  category  Interp  (Proposition  C.25). 

Diagram  refinement  (Definition  C.28)  enables  a  source  diagram  to  be  refined  by  aggregating 
compatible  interpretations  from  each  of  the  objects  in  the  source  diagram. 

2. 3  Current  Parameterization  Research 

The  use  of  parameterization  and  instantiation  is  effective  for  creating  large  objects  from  smaller 
reusable  objects.  This  section  describes  the  current  research  on  using  parameterization  with  algebraic 
specifications  to  develop  aggregate  specifications. 

Informally,  a  parameterized  object  is  an  object  that  has  both  fixed  and  variable  parts.  Instantiating 
a  parameterized  object  (often  called  parameter  passing)  fixes  the  variable  parts  based  on  an  actual 
parameter  that  meets  the  requirements  of  the  variable  part  and  enables  the  object  to  be  used  for  a  particular 
task.  A  weaker  form  of  a  parameterized  object  is  the  extensible  object.  An  extension  can  be  thought  of  as 
an  uncontrolled  instantiation.  There  is  more  freedom  in  extension  and  therefore  there  is  more  potential  for 
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misuse.  It  is  the  ability  to  be  parameterized  and  instantiated  (or  extended)  that  enables  reusable  objects  to 
be  used  in  different  contexts.  Parameterization  has  many  benefits: 

■  Parameterization  enables  the  common  parts  of  a  collection  of  related  objects  to  be  constructed 
as  a  parameterized  object  once  and  then  reused  via  instantiation  multiple  times. 

■  Once  proven  correct,  the  fixed  part  of  the  parameterized  object  will  always  be  correct  in  each 
instantiation  (assuming  the  instantiation  follows  certain  rules).  The  effort  spent  ensuring  that 
the  fixed  part  of  the  parameterized  object  is  correct  can  be  amortized  over  the  many  uses 
(instantiations)  of  the  parameterized  object. 

■  It  may  be  possible  to  limit  parameter  passing  to  “correct”  actual  parameters.  If  the  possible 
actual  parameter  can  be  pre-limited  to  a  set  that  meets  some  formal  criteria,  then  the 
parameterized  object  is  limited  to  correct  instantiations  only. 

■  A  parameterized  object  is  on  a  higher  level  of  abstraction  than  the  primitive  objects  from  which 
it  is  built. 

■  Parameterization  enables  larger  objects  to  be  built  in  an  easier  fashion  by  incorporating 
previously  developed  parameterized  objects  in  their  construction. 

■  A  collection  of  parameterized  objects  and  the  way  in  which  the  parameterized  objects  are  joined 
to  construct  a  larger  object  provide  an  explicit  stmcture  for  the  larger  object. 

Historically,  parameterization  in  an  algebraic  specification  language  has  enabled  a  specification  to 
have  one  or  more  changeable  parts  that  can  be  fixed  in  a  variety  of  different  ways,  thus  enabling  it  to  be 
(re)used  in  a  variety  of  different  contexts.  Previous  research  in  parameterized  algebraic  specifications  has 
focused  on  the  parameterization  of  a  single  “body”  specification  by  one  [BG77,  EL78,  Gan83,  EM85]  or 
more  [Hax89,  Dim98]  “formal  parameter”  specifications. 

The  two  main  classifications  of  algebraic  specification  parameterization  in  the  literature  are 
pushout-based  parameterization  and  A.-style  parameterization  [BKL91,  Wir90,  and  Gau93].  Pushout-based 
parameterization  is  referred  to  here  as  category-theory-based  parameterization  as  this  name  is  more 
inclusive  for  describing  the  actual  research. 

In  category-theory-based  parameterization  the  underlying  theory  of  parameterization  is  based  on 
specifications,  morphisms  and  diagrams  of  specifications  and  morphisms.  Instantiating  a  parameterized 
specification  involves  some  categorical  type  operation  such  as  taking  a  pushout,  multi-pushout  [JOE94],  or 
colimit  of  the  resulting  diagram.  There  are  many  variations  on  the  variable  part  of  the  parameterization 
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including  single  parameter,  multiple  parameter,  and  parameterization  by  a  diagram.  Instantiations  of  the 
parameterized  specification  can  be  nested  or  recursive. 

Unfortunately,  current  notions  of  category-theory-based  parameterization  have  two  basic  flaws 
when  used  for  developing  and  refining  large  structured  specifications.  The  first  problem  is  that  all  current 
notions  of  category-theory-based  parameterization  consider  the  body  of  the  parameterization  to  be  a  single 
parameterized  specification.  This  eliminates  all  structure  in  the  object  being  parameterized.  The  second 
problem  is  that  instantiation  of  a  parameterized  specification  results  in  a  specification  and  not  a  diagram. 
Thus  the  results  of  instantiation  lack  structure.  The  notion  of  parameterization  and  instantiation  in  current 
category  theory  based  research  lacks  structure  in  two  important  dimensions  and  therefore  is  xmsuitable  for 
developing  large  structured  specifications  in  a  manner  that  makes  the  structure  accessible  for  refinement. 

In  A.-style  parameterization,  a  parameterized  specification  is  a  specification  building  function  that 
is  written  in  the  form  of  a  ^-expression  [Wir90].  Instantiating  a  X-style  parameterization  involves 
performing  the  specification  operations  on  the  actual  parameters  as  required  by  the  specification  body.  The 
actual  parameter  specification  imdergoes  some  kind  of  computable  transformation  or  function  application. 
Although  the  body  of  a  X-style  parameterization  is  not  a  single  specification  (it  is  a  collection  of  operations 
to  be  performed  on  the  actual  parameters),  it  is  still  limited  in  current  research  to  producing  a  single 
specification  as  the  result  of  instantiation.  X-style  parameterization  does  not  fit  with  the  type  of  categorical 
operations  developed  in  this  dissertation  and  so  will  not  be  discussed  further. 

Appendix  E  describes  current  algebraic  specification  parameterization  research  in  greater  detail 
and  provides  examples  of  the  various  types  of  parameterization  and  instantiation. 

2,4  Current  Research  on  Constructing  Diagrams 

The  Specware  language  [SJ95,  SLM98]  has  a  completely  freeform  means  of  combining 
specifications  by  listing  the  arcs  and  nodes  of  a  diagram  instead  of  by  using  some  form  of  parameterization. 
As  an  example,  the  Specware  language  code  in  Figvue  2-1  creates  a  Spec  diagram  whose  colimit  is  a 
specification  for  a  Map  whose  domain  is  Nat  and  whose  codomain  is  Nat.  Each  specification  in  the  node 
list  becomes  its  own  node  in  the  diagram  and  if  the  same  specification  is  needed  for  two  different  nodes  it 
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can  be  given  two  different  “node  names”.  Each  morphism  in  the  arc  list  “connects”  two  of  the  already 
given  nodes.  Although  not  depicted,  the  arcs  can  be  named  as  well. 

The  Specware  language  diagram  statement  can  be  used  to  specify  any  finite  diagram  of 
specifications  and  morphisms.  As  such,  single-parameterization,  multi-parameterization,  and 
parameterization  by  a  diagram  (Appendix  E)  can  all  be  emulated  using  the  Specware  language.  Nested  and 
recmsive  instantiation  can  also  be  emulated.  The  term  emulated  is  used  because,  unfortunately,  each 
Specware  diagram  must  be  created  from  scratch  from  individual  specifications  and  morphisms.  The  only 
operation  available  over  diagrams  in  the  Specware  language  is  the  colimit  operation.  Diagrams  in  the 
Specware  language  cannot  truly  be  called  parameterized  objects  as  they  cannot  be  constructed  with  fixed 
and  variable  parts.  The  individual  specifications  making  up  a  diagram  can  be  extended  or  reused  in  a 
different  diagram.  The  colimit  object  of  a  diagram  can  be  extended  or  used  in  a  yet  another  diagram,  but  a 
diagram  itself  cannot  be  directly  extended  or  parameterized. 


Diagram  Map-from-Nat-to-Nat  is 

nodes  Map, 

sl:One- 

Sort,  s2:0ne-Sort, 

Dorn: Empty,  Cod: Empty 

arcs  sl->Map: 

{X  ->  Dorn}, 

sl->Dom: 

{X  ->  Nat}, 

s2->Map: 

{X  ->  Cod}, 

s2->Cod: 

{X  ->  Nat} 

end -diagram 

Spec  Map-from-Nat-to-Nat  is 

Colimit  of  Map-from-Nat-to-Nat 


Figure  2-1.  Specware  language  code  and  pictorial  representation  of  a  diagram  and  its  colimit 


If  a  parameterized  object  is  viewed  as  the  fixed  and  variable  parts  of  a  diagram,  the  specifier  must 
(re)form  both  the  fixed  part  and  its  variable  instantiation  within  the  same  Specware  diagram  each  and  every 
time  the  “parameterized  object”  is  to  be  instantiated.  Because  of  this  limitation,  for  example,  creating  an 
instantiated  Map  specification  always  requires  the  vmintuitive  diagram  construction  code  depicted  in  the 
Specware  language  code  for  the  diagram  Map-from-Nat-to-Nat  in  Figure  2-1.  The  specifier  must  know  and 
repeat  the  pattern  of  nodes  and  arcs  in  die  diagram  in  order  to  extend  (instantiate)  the  Map  specification 
each  time  a  Map  of  some  sort  to  some  other  sort  is  needed.  There  is  no  means  by  which  part  of  the  work  of 
creating  the  diagram  can  be  accomplished  and  then  stored  in  some  fashion  so  it  can  be  reused  later. 
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Appendix  D  provides  a  larger  example  of  developing  a  diagram  using  this  diagram  constmction 
approach. 

2  5  Current  Research  on  Refining  Diagrams  of  Specifications 

Assuming  that  a  structured  requirement  specification  can  be  created,  the  problem  then  switches  to 
developing  a  refinement  for  the  aggregate  specification.  Spec  interpretations  (Definition  C.20)  are  one  of 
the  primary  definitions  of  refinement  for  specifications  used  by  researchers  [Ehr82,  8X88,  and  Wir90]. 
Diagram  refinement  (Definition  C.28)  [SJ95,  SLM98]  enables  interpretation  refinements  to  be  composed 
along  with  the  specification  components  being  refined  to  form  an  interpretation  of  the  composite 
specification.  Unfortunately,  there  are  several  limitations  and  misapplications  of  diagram  refinement  and 
interpretations  as  defined  and  applied  in  [SLM98]. 

This  section  describes  each  of  die  following  limitations/misapplications  of  Spec  interpretations 
and  diagram  refinement  in  greater  detail. 

■  Diagram  refinement  using  Spec  interpretations  as  the  design  information  to  be  applied  cannot 
adequately  represent  higher-level  design  information,  specifically  “structured”  design 
information,  that  involves  one  or  more  component  specifications. 

■  Diagram  refinement  is  limited  to  a  refined  target  stmcture  that  is  inextricably  linked  to  the 
stmcture  of  the  requirement  specification;  it  does  not  allow  refinements  whose  target  diagram’s 
stmcture  is  appreciably  different  than  the  source  diagram’s  stmcture. 

■  Diagram  refinement  is  used  to  refine  “parameterized  specifications,”  a  use  for  which  it  is  not 
suited. 

2.5.1  Spec  Interpretations  vs.  higher-level  design  information 

Spec  interpretations  only  represent  specification  to  specification  refinements;  as  such  they  cannot 
adequately  represent  more  high-level  stmctured  design  information  that  may  involve  the  refinement  of 
several  “source”  specifications  at  the  same  time. 

Figure  2-2  depicts  a  collection  of  Spec  interpretations  (as  indicated  in  the  upper  left  comer)  diat 
purport  to  refine  a  Set-of-Nats  into  a  Tree-of-Nats.  Each  of  the  three  Spec  interpretations,  Nat  =>  Nat, 

Set  =:>  Tree,  and  One-Sort  =>  One-Sort,  is  individually  a  valid  Spec  interpretation.  They  can  be 
individually  applied  to  (matched  with)  the  specifications  in  the  source  diagram  and  interpretation 
morphisms  can  be  formed  between  the  Spec  interpretations  (the  triple  arrows  in  Figure  2-2)  such  that  a 
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larger  commuting  diagram  in  Spec  is  formed.  A  colimit  in  Interp  of  the  interpretations  and  interpretation 
morphisms  results  in  an  interpretation  Set-of-Nat  Tree-of-Nat.  From  outward  appearances,  the  diagram 
refinement  is  a  success,  yet  the  resulting  Spec  interpretation  is  not  what  is  wanted. 

The  diagram  refinement  shown  in  Figure  2-2  is  incorrect  (or  incomplete)  because  in  order  for  a 
Tree  to  store  elements  in  sorted  order  there  must  be  a  defined  and  indicated  total  order  operation  over  the 
element  sort  of  the  Tree  specification,  in  this  case  the  sort  Nat.  The  sort  Nat  has  several  such  operations; 
among  them  are  the  “Less  than”  and  “greater  flian”  operations.  However,  the  diagram  refinement  did  not 
indicate  which  total  order  operation  over  the  sort  Nat  should  be  used,  and  therefore  the  diagram  that 
produced  the  Tree-of-Nat  specification  is  incorrect.  Storing  design  information  as  Spec  interpretations  does 
not  allow  such  information  to  be  specified  as  it  is  an  emergent  property  of  the  collection  of  Spec 
interpretations  making  up  the  diagram  refinement  as  opposed  to  any  individual  Spec  interpretation. 


Figure  2-2.  Incorrect  collection  of  interpretations  for  a  diagram  refinement 

Figure  2-3  depicts  a  correct  diagram  refinement  of  Set-of-Nat  to  Tree-of-Nat,  as  the  One-Sort 
specification  is  refined  via  the  Spec  interpretation  One-Sort  =>  Total-Order  instead  of  the  Spec  identity 
interpretation  One-Sort  One-Sort.  In  Figure  2-3,  when  interpretation  morphisms  are  developed  between 
the  Spec  interpretations,  the  specification  Total-Order  ensures  that  the  element  sort  and  the  total  order 
operation  over  the  element  sort  in  the  Tree  specification  will  be  combined  with  the  Nat  sort  and  the  total 
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order  operation  over  Nats.  This  ensures  that  the  target  diagram  of  the  diagram  refinement,  the  specification 
Tree-of-Nat,  and  the  resulting  composite  Spec  interpretation,  Set-of-Nat^^Tree-of-Nat,  is  correct. 

While  diagram  refinement  as  a  whole  can  adequately  handle  the  refinement  depicted  in  Figure  2-3, 
representing  design  information  as  individual  Spec  interpretations  cannot  adequately  represent  the  higherr 
level  requirements  that  must  be  present  for  the  collection  of  Spec  interpretations  to  be  what  is  wanted-  It  is 
the  developer’s  knowledge  that  must  be  used  to  distinguish  between  the  incorrect  diagram  refinement  in 
Figure  2-2  and  the  correct  diagram  refinement  in  Figure  2-3  and  not  anything  that  can  be  specified  using 
Spec  interpretations  and  diagram  refinement  alone.  In  other  words,  correct  and  compatible  (with  each 
other)  individual  interpretation  refinement  choices  do  not  always  result  in  a  correct  overall  choice,  as 
additional  design  information  beyond  what  is  contained  in  a  Spec  interpretation  is  needed. 


Figure  2-3.  Correct  collection  of  interpretations  for  a  diagram  refinement 

Part  of  the  problem  is  that  specifications  Set  and  One-Sort  can  be  viewed  linked  together  in  a  form 
of  parameterization  that  may  not  be  taken  into  account  when  selecting  individual  interpretations.  In  Figure 
2-3  the  formal  parameter  being  refined  is  specification  One-Sort,  the  body  being  refined  is  specification 
Set,  and  the  actual  parameter  being  refined  is  specification  Nat.  In  [Sri97]  an  approach  for  refining 
parameterized  specifications  (referred  to  as  pspecs  in  the  reference)  was  developed  that  Imked  the 
refinements  of  the  “formal  parameter”  specification  and  refinements  of  the  “body”  specification  and 
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allowed  them  to  be  refined  as  a  unit.  The  pspec  refinement  technique  described  in  [Sri97]  did  not  describe 
how  the  refinement  of  pspecs  fit  within  the  larger  context  of  a  diagram  in  which  it  was  embedded.  Nor 
could  it  handle  the  case  depicted  in  Figure  2-3  where  the  formal  parameter  of  die  target  pspec  (Total-Order) 
is  required  to  be  stronger  (require  more  properties)  than  the  formal  parameter  of  the  source  pspec  (One- 
Sort)  as  the  refinement  was  independent  of  the  actual  parameter.  In  addition,  the  technique  as  described 
was  limited  to  having  a  single  specification  as  the  body  and  a  single  specification  as  the  formal  parameter. 

2.5.2  Restructuring  refinements 

Diagram  refinement  does  not  enable  one  to  restructure  the  diagram  while  it  is  being  refined,  as  a 
diagram  refinement  is  made  up  of  a  collection  of  Spec  interpretations  that  are  inherently  between  a  single 
source  specification  and  a  corresponding  target  specification.  In  diagram  refinement,  the  structure  of  the 
requirement  specification  is  directly  reflected  in  the  structure  of  the  refinement  and  eventual 
implementation. 

In  [SST92]  the  authors  differentiate  between  parameterized  specifications  and  specifications  of 
parameterized  programs.  Parameterized  specifications  are  used  to  structure  the  requirement  specifications. 
A  related  concept,  the  specification  of  parameterized  programs,  is  used  to  specify  the  programming 
language  modules  that  arise  when  designing  an  implementation,  i.e.  the  stmcture  of  the  implementation. 
The  two  structures,  the  requirement  specification  structure  and  the  implementation  structure,  may  be  very 
different  from  each  other  depending  on  what  design  choices  are  made.  If  the  structure  of  the  requirement 
specification  and  implementation  are  identical,  then  there  is  no  cause  for  concern,  as  diagram  refinement 
uses  the  structure  of  the  requirement  specification  to  infer  (or  at  least  place  a  bound  on)  the  structure  of  the 
implementation.  However,  if  the  desired  implementation  structure  is  (appreciably)  different  than  the 
requirement  specification  structure,  then  interpretations  and  diagram  refinement  alone  cannot  be  used  to 
accomplish  tiie  refinement. 

Figure  2-4  provides  an  example  of  the  possible  differences  between  a  requirement  structure  and  an 
implementation  structure.  If  the  requirement  specification  contains  a  set  of  pairs,  as  depicted  on  the  left  in 
Figure  2-4,  flien  using  diagram  refinement  and  interpretations,  one  can  choose  from  among  a  number  of 
refinements  for  the  individual  specifications  in  the  diagram.  For  example,  the  Set  specification  could  be 
refined  into  Bags,  Lists,  Tree,  Bit-vectors,  etc.,  and  the  Pair  specification  could  be  refined  into  a  record- 
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type  with  two  fields,  a  Nat  field  and  a  Flag  field.  However,  there  is  no  way  to  refine  the  diagram  on  the  left 
in  Figure  2-4  to  the  one  on  the  right  using  interpretations  and  diagram  refinement. 

On  the  right  is  a  Map  from  the  first  Pair  element  (A)  to  a  Set  of  the  second  pair  element  (B).  This 
Map-to-Set  stmcture  on  the  right  can  be  defmitionally  extended  with  operations  over  the  <A,  B>  pair  so  as 
to  emulate  a  Set  of  Pairs.  Thus  the  stmcture  on  the  right  can  be  extended  so  as  to  be  an  implementation  of 
the  stmcture  on  the  left.  Refining  the  diagram  on  the  left  to  the  diagram  on  the  right  in  Figure  2-4  is  not 
possible  using  diagram  refinement. 


However,  given  that  one  knows  in  advance  that  such  a  stmctured  refinement  is  desired,  one  can 
develop  the  requirement  specification  as  depicted  in  Figure  2-5  (or  one  can  restmcture  the  requirement 
specification  to  appear  as  depicted  in  Figure  2-5  whether  or  not  it  was  developed  that  way  initially).  In 
Figure  2-5,  the  derived  specification  Set-of-Pair  can  be  refined  as  a  unit  given  a  Spec  interpretation 
Set-of-Pair  =>  Map-to-Set.  In  other  words,  to  apply  the  “stmctured”  design  information,  one  has  to  either 
develop  the  requirement  specification  with  the  particular  design  refinements  in  mind,  or  one  must 
restmcture  the  requirement  specification  once  it  is  realized  that  a  particular  refinement  is  desired.  In  either 
case  the  effect  is  to  remove  the  stmcture  or  “collapse”  the  stmcture  prior  to  the  refinement  that  is  taking 
place  (prior  to  the  interpretation  being  applied). 
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One-Sort  A  B 


Figure  2-5.  Multiple  levels  of  requirement  specification  structure 

Normally  one  applies  an  interpretation  in  diagram  refinement  by  identifying  the  source 
specification  of  an  interpretation  with  a  specification  in  the  diagram  being  refined.  This  can  be 
accomplished  mechanically  via  a  simple  search  through  a  library  of  design  refinements  (i.e.  Spec 
interpretations).  How  can  one  determine  that  the  “collapsed”  Spec  interpretation  source  specification  (i.e. 
the  specification  Set-of-Pair)  can  be  applied  to  a  requirement  specification  without  first  restructuring  the 
requirement  specification  and  why  would  one  collapse  the  requirement  specification  without  previously 
identifying  that  a  particular  Spec  interpretation  refinement  could  be  applied  to  it?  Again,  Spec 
interpretations  and  diagram  refinement  alone  are  not  up  to  the  task. 

2.5.3  Parameter  vs.  Body  refinement 

Certain  specifications  are  called  body,  formal  parameter,  and  actual  parameter  based  on  their 
relationship  with  each  other;  see  Appendix  E  and  Section  4.2.1.  It  ought  to  be  possible  to  refine  the  actual 
parameter  in  a  manner  that  is  independent  of  the  refinement  of  the  body.  In  general,  this  is  not  possible  in 
diagram  refinement. 

In  the  Spec  interpretation  in  Figure  2-6,  the  Flag  sort  is  implemented  as  a  subsort  of  the  Nat  sort, 
namely  the  subsort  containing  the  Nat  values  1,  2,  and  3.  The  constant  Flag  operations.  Green,  Yellow,  and 
Red  are  implemented  as  the  Nat  values  1, 2,  and  3.  As  the  requirement  specification  is  a  Set  of  Flag,  one 
ought  to  be  able  to  refine  the  Flag  specification  via  the  interpretation  Flag  =>Nat  depicted  in  Figure  2-6, 
independently  of  any  refinement  being  done  to  the  Set  specification. 
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Figure  2-6.  Interpretation:  Flag  as  Nat 


Such  a  diagram  refinement  is  depicted  in  Figure  2-7  where  the  Spec  interpretations  for  the  Set 
specification  and  the  One-Sort  specification  are  Spec  identity  interpretations  and  flie  Spec  interpretation  for 
the  Flag  specification  is  as  depicted  in  Figure  2-6.  Essentially,  in  the  diagram  refinement  in  Figure  2-7,  the 
design  choice  is  to  refine  the  Flag  sort  in  the  Flag  specification  to  a  sub-sort  of  the  Nat  sort.  The  question, 
as  indicated  by  the  two  “?”s  in  Figure  2-7,  is  how  to  form  the  required  interpretation  morphisms  between 
die  three  interpretations  making  up  the  diagram  refinement. 

The  diagram  in  Figure  2-8  is  a  flattened  view  of  the  diagram  refinement  pictured  in  Figure  2-7.  It 
depicts  the  morphisms  between  the  specifications  making  up  the  diagram  refinement  as  well  as  (some  of) 
the  signature  element  mappings  between  the  various  specifications.  Those  signature  element  mappings 
indicate  the  needed  interpretation  morphisms  that  should  form  a  commuting  diagram.  Unfortunately,  a 
commuting  diagram  cannot  be  formed  given  the  three  interpretations  listed  in  Figure  2-7. 
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Figure  2-8.  Required  interpretation  morphism  cannot  be  formed 


The  “?”  in  Figure  2-8  indicates  the  problem.  In  order  for  the  lower  left  square  of  specifications 
One-Sort,  One-Sort,  Flag,  and  FlagAsNat  to  be  a  commuting  square,  the  sort  X  in  the  mediator  One-Sort 
specification  must  be  mapped  to  the  sort  Flag  in  the  FlagAsNat  specification.  On  the  other  hand,  in  order 
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for  the  lower  right  square  of  specifications,  One-Sort,  One-Sort,  FlagAsNat,  and  Nat  to  form  a  commuting 
square,  the  sort  X  in  the  mediator  One-Sort  specification  must  be  mapped  to  the  sort  Nat  in  the  FlagAsNat 
specification.  Since  both  mappings  cannot  be  possible,  one  or  the  other  of  the  lower  squares  will  not  be  a 
commuting  square  and  the  diagram  in  Figure  2-8  as  a  whole  will  not  be  a  commuting  diagram. 

The  solution  to  diis  dilemma  (according  to  an  example  diagram  refinement  in  [SLM98])  is  to  use 
interpretation  schemes  for  the  Set  and  One-Sort  specifications  rather  than  the  Spec  interpretations  that  are 
currently  being  used.  An  interpretation  scheme  is  an  “interpretation”  where  the  target  to  mediator 
morphism  is  not  a  definitional  extension  [SLM98].  In  Figure  2-9,  the  interpretation  scheme 
One-Sort  ->  Two-Sort-Subsort  <r-  One-Sort  is  used  to  introduce  an  undefined  subsort  relationship  in  the 
mediator.  (Hence  the  reason  it  is  an  interpretation  scheme  instead  of  an  interpretation.)  If  one  examines 
the  bottom  left  and  right  squares  in  Figure  2-9,  it  is  evident  that  these  are  commuting  squares.  Thus  the 


problem  depicted  in  Figure  2-8  has  been  solved.  Unfortunately,  the  solution  has  introduced  a  new  problem. 


Figure  2-9.  Interpretation  scheme  used  to  partially  fix  the  problem  depicted  in  Figure  2-8 
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The  newly  introduced  Two-Sort-Subsort  mediator  specification  that  solved  the  previous  problem 
must  also  have  a  morphism  to  the  Set  mediator  specification.  This  means  that  the  sorts  X  and  Y  (and  the 
binary  relation  S)  in  the  Two-Sort-Subsort  mediator  specification  must  all  be  mapped  to  signature  elements 
of  the  Set  mediator  specification.  The  sort  X  in  specification  Two-Sort-Subsort  must  be  mapped  to  the  Sort 
E  in  the  Set  specification  in  order  for  the  upper  right  square  of  specifications  to  commute.  In  order  for  the 
upper  left  square  of  specifications  to  commute  the  sort  Y  must  be  mapped  to  some  subsort  of  E  in 
specification  Set  (and  the  binary  relation  S  must  be  mapped  to  some  binary  relation  over  E).  No  such 
subsort  or  binary  relation  exists  in  the  Set  specification,  therefore  the  ”fix”  depicted  in  Figure  2-9  is  only  a 
partial  solution. 

In  order  to  correct  the  problem  using  diagram  refinement,  the  Set=>Set  Spec  identity  interpretation 
must  also  be  replaced  with  an  inteipretation  scheme.  This  “final  fix”  to  the  problem  is  not  depicted,  but  it 
involves  developing  a  specification  Two-Set-Subsort  that  has  two  copies  of  the  Set  specification  (referred 
to  here  as  “A”  and  “B”  copies)  and  that  will  serve  as  the  mediator  of  an  interpretation  scheme 
Set->Two-Set-Subsort<-Set.  In  the  Two-Set-Subsort  specification,  the  element  sort  associated  with  the  Set 
sort  “B”  must  be  defined  to  be  a  subsort  of  the  element  sort  associated  with  the  Set  sort  “A”,  and  the 
operations  over  the  Set  sort  “B”  must  all  be  defined  in  terms  of  the  operations  over  the  Set  sort  A  .  The 
binary  relation  that  defines  the  element  subsort  is  itself  undefined.  (Which  is  why  it  is  an  interpretation 
scheme  instead  of  in  interpretation.)  A  similar  problem  and  its  fully  coded  solution  can  be  found  in 
[SLM98]. 

As  can  be  seen  in  the  progression  from  Figure  2-6  to  Figure  2-9,  a  simple  Spec  interpretation  of  an 
“actual  parameter”  (Flag)  that  involves  a  sub-sort  is  propagated  up  to  the  “formal  parameter”  (One-Sort) 
and  then  ultimately  propagated  over  to  the  “body”  (Set).  Not  only  is  the  refinement  of  the  parameter 
specification  not  independent  of  the  refinement  of  the  body  specification,  but  one  cannot  even  refine  the 
body  specification  with  the  identity  interpretation  while  the  actual  parameter  is  being  refined. 

If  the  actual  requirement  specification  were  a  Set-of-Set-of-Flags  then  the  ripple  effect  would 
extend  even  further  over  to  the  “formal  parameter”  and  “body”  interpretations  of  the  outer  Set  specification 
as  well.  If  one  had  a  more  complex  requirement  specification  such  as  the  Petri  Net  specification  in 
Appendix  D,  then  theoretically  a  simple  refinement  such  as  Place  =>  Nat  could  ripple  to  all  the  other 
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specifications  in  the  diagram.  At  least  in  the  Set-of-Set-of-Flags  case  once  the  complex 
Set->Two-Set-Subsort<-Set  interpretation  is  formed  it  can  be  reused  for  both  the  inner  and  outer  Set 
specification  refinements.  (Actually  non-refinements  since  the  Set  specification  is  being  refined  to  itself  so 
one  is  not  refining  the  Set  specification  at  all.) 

An  alternate  design  choice  for  refining  a  Set-of-Flags  would  be  to  refine  the  Flag  sort  to  be  a 
quotient  sort  of  Nat  (i.e.  all  Nats  equivalenced  by  their  remainder  divided  by  3)  instead  of  refining  it  to  be  a 
subsort  of  sort  Nat.  If  this  alternate  design  choice  were  chosen  then  the  same  ripple  effect  would  apply, 
except  now  instead  of  rippling  a  subsort  through  the  One-Sort  and  Set  identity  interpretations  one  would 
have  to  ripple  a  quotient  sort  through  the  identity  interpretations  and  develop  quotient  sort  interpretation 
schemes  instead  of  subsort  interpretation  schemes.  As  a  final  complication,  if  one  were  to  try  to  refine  one 
of  the  Set  specifications  to  a  List  specification  at  the  same  time  (during  the  same  diagram  refinement  step) 
as  either  of  the  Flag  to  Nat  refinements  were  being  accomplished,  then  the  propagation  of  problems  would 
be  even  more  severe,  if  not  impossible,  to  surmoimt. 

The  reason  this  refinement-rippling  problem  in  diagram  refinement  occurs  at  all  is  that  diagram 
refinement  appears  to  be  solving  the  wrong  problem.  The  underlying  meaning  of  the  example  diagram 
refinement  Set-of-Flag  to  Set-of-Nat  is  that  given  an  implementation  of  Set-of-Nat  one  can  construct  (via  a 
definitional  extension)  an  implementation  of  Set-of-Flag.  Starting  out  with  a  Set-of-Nat  and  trying  to 
develop  a  Set-of-Flag  is  not  the  problem  that  should  be  solved.  Imagine  that  one  had  a  Set  module  and 
natural  numbers  and  that  one  was  trying  to  develop  a  Set-of-Flag  implementation.  Would  the  first  action 
be  to  develop  a  Set  of  natural  numbers  by  instantiating  the  Set  module  with  natural  numbers  and  then 
secondly  work  with  that  instantiated  Set-of-Nats  module  to  develop  a  Set  of  Flags?  Or  would  one  first  use 
the  natural  numbers  to  define  the  Flag  data  type  and  then  secondly  instantiate  the  Set  module  with  the 
newly  defined  Flag  data  type  ignoring  the  fact  that  a  Set-of-Nat  instantiation  could  be  done  at  all?  The 
latter  choice  is  obviously  the  correct  choice.  However,  since  the  goal  of  diagram  refinement  for  this 
particular  problem  is  to  develop  a  Spec  interpretation  from  the  Set-of-Flag  specification  to  the  Set-of-Nat 
specification,  it  is  the  former  choice  that  is  the  problem  that  is  being  solved  by  diagram  refinement. 
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2,6  Summary 


This  chapter  has  described  the  existing  research  for  representing  and  applying  software  design 
information  by  classifying  and  analyzing  the  various  formal  development  methodologies.  The  latter 
sections  of  this  chapter  described  specific  problems  with  creating  and  refining  large  structured  requirement 
specifications  that  occurs  with  existing  approaches.  The  original  research  that  solves  these  problems  is 
presented  in  the  following  chapters. 
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3  Theory  of  Diagram  Categories 


This  chapter  develops  the  theory  of  diagram  categories  that  underlies  the  category  of  diagrams  of 
specifications  proposed  in  Chapter  4.  The  material  in  Section  3.5  of  this  chapter  defines  a  collection  of 
operations  over  diagrams  that  are  used  in  turn  to  define  the  syntax  for  creating  and  manipulating  diagrams 
developed  in  Chapter  5.  The  colimit  defined  in  this  chapter  underlies  the  application  and  con^osition  of 
design  information  presented  in  Chapter  6. 

The  primary  contribution  of  this  chapter  is  the  development  of  the  diagram  category  and 
operations  over  diagrams.  The  diagram  category,  dX,  is  defined  generically  over  any  category  X,  instead 
of  a  specific  category  such  as  Spec^  as  this  simplifies  its  development  by  eliminating  extraneous  details  of 
the  underlying  category.  This  method  of  development  also  clearly  demonstrates  the  relationship  between 
certain  properties  and  operations  in  the  underlying  category  X  and  the  corresponding  properties  and 
operations  in  the  category  dK. 

Informally  the  objects  of  category  dX  are  all  the  diagrams  of  a  category  X  and  the  arrows  of 
category  dX  are  collections  of  X-arrows  with  certain  structure  and  content-preserving  properties.  A  dX- 
arrow, consists  of  an  X-arrow  from  each  X-object  in  the  source  ^/X-object  (the  X  diagram  D\)  to 
an  associated  X-object  in  the  target  ^DC-object  (the  X  diagram  D2)  that  forms  an  even  larger  diagram  in 
category  X.  Figure  3-1  depicts  an  example  arrow  :Di^D2  in  a  category  dX  as  well  as  a  possible 
underlying  structure  of  the  objects  and  arrows  in  a  category  X. 
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For  (the  collection  of  X-arrows)  Di-^D2  to  be  a  diagram  morphism  the  diagram  stmcture  of  Di 
must  be  preserved  in  D2  (via  a  structure-preserving  mapping),  the  objects  within  Dj  must  be  preserved  in 
D2  (via  an  X-arrow  mapping  between  the  objects),  and  the  arrows  within  Di  must  be  preserved  in  D2  (via 
the  corresponding  arrows  forming  a  commutative  square  with  the  arrows  between  the  diagrams).  The 
category  of  shapes  and  the  arrow  category  of  category  X  are  used  to  define  these  properties  formally. 

Sections  3.1  and  3.2  contain  background  information  and  “lemmas”  necessary  for  later  chapters. 

In  Section  3.1  the  category  of  shapes  is  formally  defined  and  proved  to  be  cocomplete.  In  Section  3.2  the 
arrow  category,  X”^,  of  a  category  X  is  formally  defined  and  some  of  the  operations  that  are  relevant  to  the 
category  of  diagrams  being  developed  are  defined.  In  Section  3.3  the  notion  of  a  morphism  between 
diagrams  is  formally  defined  using  the  category  of  shapes  and  the  Arrow  category.  Also  in  this  section 
diagrams  and  diagram  moiphisms  of  any  category  X  are  proved  to  be  the  objects  and  arrows  of  a  category 
rfX.  In  Sections  3.4  and  3.5  the  operations  Flatten,  Partition,  Join,  and  Fold  are  defined  as  well  as  the 
notion  of  a  diagram  extension,  diagram  parameterization  and  diagram  instantiation.  In  Section  3.6  a 
colimit  operation  is  defined  over  Nice  category  rfX  diagrams  (diagrams  that  flatten  to  commuting  category 
X  diagrams). 

3. 1  The  Category  of  Shapes 

An  understanding  of  this  section’s  material,  especially  the  terminology,  is  critical  for 
understanding  Sections  3.3  through  3.6  as  well  as  some  of  the  later  chapters.  The  proof  that  the  category  of 
shapes  is  cocomplete  (Section  3.1.3)  is  original.  The  concept  of  a  diagram  being  defined  as  a  functor  is 
common  in  category  theory  [AHS90].  The  concept  of  using  a  category  of  shapes  to  capture  and  relate 
diagram  structure  information  comes  from  [SJ95]. 

3.1.1  A  shape  category  vs.  the  category  of  shapes 

A  shape  category  or  a  shape  can  be  thought  of  as  the  structural  essence  of  a  category  (the  number 
and  orientation  of  the  objects  and  arrows  in  a  category).  For  example,  every  category  with  a  single  object 
and  a  single  arrow  has  the  structure  (shape):  This  category  is  commonly  referred  to  as  Category  1  for 

its  single  object  and  single  identity  arrow  [Gol84].  A  category  with  two  objects  and  three  arrows  must  have 
one  of  the  following  two  shapes:  or  ^  As  these  shape  abstractions  have  their  own 
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objects  and  arrows,  and  some  of  these  arrows  are  identity  arrows  and  these  arrows  compose  and  are 
associative  (as  defined  by  any  of  their  underlying  “concrete”  categories),  each  shape  is  itself  a  category. 
Deflnition  3.1.  Shape  category*.  The  objects  of  a  shape  category  are  called  nodes;  the  arrows  of  a  shape 
category  are  called  arcs,  with  each  arc  having  a  source  and  target  node.  Each  node  has  an  identified 
identity  arc,  and  for  every  pair  of  arcs  that  form  a  “path”,  3 ,  there  exists  a  composed  arc 

The  composition  of  arcs  is  associative.  As  noted  in  [AHS90],  the  definitions  of  a  shape  category  (or 
scheme  as  it  is  referred  to  there)  and  a  category  are  identical. 

A  shape  category  is  useful  for  its  structural  properties.  Note  that  the  physical  orientation  of  the 
shape  category  is  unimportant.  Thus  the  shape  category  as  depicted  in  Figure  3-2  could  be  rotated,  flipped 
or  manipulated  via  some  graph  isomorphism  and  it  would  still  be  the  same  shape  category. 


Figure  3-2.  An  example  shape  category 

Functors  between  categories  have  a  direct  relationship  with  these  shape  categories.  For  example, 
each  category  with  shape  has  two  functors  to  each  category  with  shape  and  two  functors  to 

each  category  with  shape  ^  The  reason  a  category  of  the  latter  shape  has  only  two  functors  to  it 

and  not  three  is  because  each  object  can  only  have  one  identity  arrow  and  functors  must  preserve  identity 
arrows.  Every  category,  regardless  of  its  shape,  has  a  functor  to  every  category  of  shape  0^.  There  are 
eight  functors  from  each  category  with  shape  to  each  category  with  the  shape  depicted  in  Figure 

A-3  (four  that  “preserve  the  separation  of  nodes”  and  four  that  do  not).  There  are  five  functors  from  the 
shape  depicted  in  Figure  A-3  to  shape  Each  of  these  “always  exists”  functors  is  a  morphism 

between  shapes  (and  a  functor  between  shape  categories.)  A  functor  between  shape  categories  captures  die 
structural  essence  of  a  functor  between  “concrete”  categories  and  abstracts  away  the  underlying  meaning  of 
the  mapping  of  the  objects  and  arrows  between  the  “concrete”  categories. 

Deflnition  3.2.  Shape  Junctor.  A  shape  functor  is  a  functor  between  shape  categories,  i.e.  any  mapping  of 
the  nodes  and  arcs  of  one  shape  category  to  another  such  that  identity  arrows  and  arrow  conqjosition  is 
preserved  by  the  mapping. 
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Terminology:  The  terms  shape  and  shape  category  are  used  interchangeably  and  the  terms  shape 

morphism  and  shape  category  functor  are  used  interchangeably  based  on  the  context.  The  objects  of  a 
shape  category  are  referred  to  as  nodes  and  the  arrows  of  a  shape  category  are  referred  to  as  arcs. 

Definition  33.  Category  of  shapes:  The  objects  of  the  category  of  shapes  are  all  the  shapes;  the  arrows  of 
the  category  of  shapes  are  all  the  shape  morphisms.  The  category  of  shapes  is  a  full  sub-category 
(Definition  A.  14)  of  category  Cat. 

3.1.2  Classifying  shape  morphisms 

Shape  morphisms  can  be  classified  by  the  way  they  “preserve”  the  structure  of  a  shape. 

A  shape  monomorphism  a:Gi^G2  associates  each  node  and  arc  in  shape  Gi  with  a  distinct  node 
and  arc  in  shape  G2.  A  shape  monomorphism  preserves  the  shape  “structure”  of  shape  Gi  intact  without 
any  collapsing  in  shape  G2.  However,  a  shape  monomorphism  does  not  rule  out  additional  unmapped  arcs 
and  nodes  from  occurring  in  shape  G2. 

In  a  shape  epimorphism  a:Gi— >G2  every  node  and  arc  in  shape  G2  is  mapped  to  by  at  least  one 
node  and  arc  from  shape  Gi  thus  the  structure  of  G2  is  completely  “covered”  by  the  structure  of  Gi. 
However,  more  than  one  shape  Gi  arc  or  node  may  be  mapped  to  a  single  shape  G2  arc  or  node  and  thus  the 
structure  shape  of  Gi  may  be  collapsed  in  its  mapping  to  shape  G2. 

A  shape  isomorphism  in  the  category  of  shapes  neither  extends  nor  collapses  the  structure  of  the 
source  category  in  the  target  category.  Essentially  no  change  in  structure  has  occurred  based  on  a  shape 
isomorphism. 

3.1.3  Colimits  in  the  category  of  shapes 

In  this  section  the  category  of  shapes  is  proved  to  be  cocomplete  (Definition  A.  18)  by  first  proving 
that  it  has  all  pushouts  (Definition  A.  1 5). 

Informally,  a  pushout  in  the  category  of  shapes  combines  two  shapes  based  on  the  sharing 
indicated  by  a  third  shape.  A  pushout  diagram  in  the  category  of  shapes,  Gbi  Ga  Gbi,  is  a 

an  object  Go  that  merges  shapes  Gbi  and  Gb2  based  on  the  sharing  indicated  by  shape  Ga*  A  pushout 
object  in  the  category  of  shapes  preserves  as  much  of  the  shape  structure  as  possible  of  the  shape  objects 
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maVing  up  the  pushout  diagram  while  not  adding  additional  extraneous  stracture  or  combining  more  of  the 
stmcture  than  is  required. 

Figure  3-3  depicts  an  example  pushout  in  the  category  of  shapes.  It  has  been  simplified  in  order  to 
avoid  cluttering  Ae  figure.  Specifically,  the  identity  arrows  and  arrow  compositions  within  die  individual 
shapes  are  deliberately  not  depicted.  In  addition,  the  arrows  between  the  shape  objects  (the  fimctors 
between  the  shape  categories)  depicts  only  the  mapping  of  nodes  to  nodes;  the  mapping  of  arcs  to  arcs  (in 
this  case)  can  be  uniquely  determined  from  the  node  mappings.  Finally,  the  arrow  Ga-^Gc  has  also  been 
left  off  the  figure,  as  it  can  easily  be  determined. 


Figure  3-3.  Underlying  structure  of  a  pushout  in  the  category  of  shapes 


Proposition  3.4.  The  category  of  shapes  has  all  pushouts. 

Proof; 

Constmction  r>f  a  piisbnut  object:  Given  a  diagram  in  die  category  of  shapes  of  the  form 
Gg,  Ga  -aB2->  Gb2,  the  pushout  object  Gc  is  constructed  as  follows: 

First,  the  nodes  and  arcs  of  shapes  Ga,  Gbi  and  Gb2  are  labeled  so  as  to  be  distinct  from  each 
other.  This  has  been  done  for  the  nodes  only  in  the  example  pushout  diagram  in  Figure  3-4.  (Ignore  the 
labels  in  the  pushout  object  Gc  for  now.) 

Second,  the  shape  morphism  Obi  is  used  to  derive  a  collection  of  equivalent  groups  of  nodes  and 
arcs  over  its  domain  and  codomain  objects  Ga  and  Gbi.  The  equivalence  groups  are  defined  as  follows: 
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For  each  node  ti  e  Objects(GBi),  the  equivalence  group  tibi  is  defined  as  follows; 

T|bi  =  q  u  {  a  1  a  e  Objects(GA)  a  OBi(a)  =  q} 

For  each  arc/ e  Arrows(GBi),  the  equivalence  group^i  is  defined  as  follows. 

/bi  =/'-' { f  I  g  ^  Arrows(GA)  A  (Jbi(  g  )  =/} 

Thus,  each  q  6  Objects(GBi)  has  an  associated  equivalence  group  qBi  that  contains  one  Gbi  object 
and  zero  or  more  Ga  objects.  Each/€  Arrows  (Gbi)  has  an  associated  equivalence  group/si  that  contains 
one  Gbi  arrow  and  zero  or  more  Ga  arrows. 

Similarly  the  shape  moqrhism  Cb2  is  used  to  develop  a  collection  of  equivalent  groups  of  nodes 
(qB2)  and  of  arcs  (/b2)  associated  with  the  nodes  (q)  and  arcs  (/)  of  shape  object  Gb2. 

Third,  the  equivalence  groups  associated  with  the  arcs  and  nodes  of  shapes  Gbi  and  Gb2  are  then 
merged  based  on  die  common  nodes  and  arcs  of  shape  Ga  to  form  a  merged  collection  of  equivalent  nodes, 

{qc},  and  arcs,  {/c}>  defined  as  follows: 

Let  the  |x|  operation  be  the  size  operation  over  an  equivalent  group  x. 

Let  Obi  be  the  mapping  fi-om  a  node  q  e  Objects(GA)  or  arc/e  AttowsCGa)  to  die  associated 
equivalence  group  of  Gbi  of  which  it  is  a  member. 

Let  Ob2  be  the  mapping  from  a  node  q  €  Objects(GA)  or  arc/e  AttowsCGa)  to  the  associated 
equivalence  group  of  Gb2  of  which  it  is  a  member, 

{qc}  =  (tlBi  I  r\  €  Objects(GBi)  and  |qBi|  =  1}  {qBZ  I  q  e  Objects(GB2)  and  Iqail  =  1}  u 
{qmerge  I  qmerge  =  ^BiCq)  u  aB2(q)  where  q  e  Objects(GA) }, 

{f^  }  =  I/e  Arrows(GBi)  and  1/bi|  =  1}  u  {/b2  !/e  Airows(GB2)  and  I/bjI  -  1}  u 
{/merge  I/merge  =  aBl(/)  Osiif)  where/€  AtTOWsCGa)  } 

Thus,  each  node  equivalence  group  in  the  set  {qc}  is  either  a  singleton  node  equivalence  group 

from  the  shapes  Gbi  and  Gb2  or  is  a  merged  equivalence  group  from  those  shapes  based  on  the  common 

nodes  from  shape  Ga-  Each  arc  equivalence  group  in  the  set  {fc}  is  similarly  characterized  over  the  arc 

equivalence  groups  of  shapes  Ga,  Gbi,  and  Gb2- 

Finally,  each  node  equivalence  group  in  {tic}  becomes  a  single  node  in  the  pushout  object  Gc  and 

each  arc  equivalence  group  in{/c}  becomes  a  single  arc  in  the  pushout  object  Gc-  Each  node 

r\  G  Objects(Gc)  has  a  unique  associated  equivalence  group  t|c  ht  constructed  set  {ilc}  each  arc 

/g  Arrows(Gc)  has  a  unique  associated  equivalence  group /c  in  the  constructed  set  {fc}-  For  each 

f  G  Arrows(Gc),  dom(/)  and  cod(/)  are  defined  as  follows: 

dom(/)  =  ri  I  T|  G  Objects(Gc)  a  qc  =  dom(/c) 
cod(/)  =  q  1  q  G  Objects(Gc)  a  qc  =  cod(/c) 

where  dom(yc )  =  {cc  |  a  =  dom(  g  )  for  some  g  e  /c  }, 

i.e.  the  set  of  domain  objects  of  the  set  of  arrows  in  the  arc  equivalence  group /c- 
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where  cod(/c  )  =  {a  |  a  =  cod(  g  )  for  some  g  e  /c  }, 

i.e.  the  set  of  codomain  objects  of  the  set  of  arrows  in  the  arc  equivalence  group/c- 

The  predicates  dom(/c  )  e  {  qc  }  and  cod(/c )  e  {  qc  }  are  guaranteed  by  the  constraction  of  the 
sets  {qc}  and  {/c}. 

The  constmcted  object  is  a  shape  category:  The  collection  of  nodes  and  arcs  making  up  Gc  are  a  shape 
category  as  each  node  has  an  identity  arc,  all  adjacent  arcs  have  an  associated  conqjosite  arc,  and 
composition  is  associative. 

For  each  q  e  Objects(Gc)  there  exists  mf  e  Arrows(Gc)  such  that  dom(/c)  =  qc  =  cod(/c)), 
i.e./  =  idr^,  the  identity  arc  of  node  q. 

For  each /  g  e  Arrows(Gc),  g  °  /  e  Arrows(Gc) 

because  the  individual  arrows  comprising  the  arc  equivalence  groups/:  and  gc  that  have 
an  adjacent  node  also  compose  and  that  collection  of  compositions  will  also  be  equal  to 
an  existing  arc  equivalence  group. 

The  shape  morphisms  aBi’iGBi-^Gc  and  aB2’;GB2-»Gc  are  derived  from  the  mapping  that  takes 
each  arc  and  node  in  Gbi  and  Gb2  (respectively)  to  the  associated  equivalence  group  in  shape  Gc  of  which  it 
is  a  member.  Shape  object  Gc  is  part  of  a  commuting  square  by  constraction  of  the  morphisms  Obi’  and 
Ob:’-  The  constructed  object  Gc  always  exists  as  this  method  of  constraction  will  work  with  any  shape 
category  diagram  Gbi  Ga  -ob2->  Gb2- 


Figure  3-4.  A  distinct  node  labeling  for  a  pushout  in  the  category  of  shapes. 
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As  an  example  of  the  pushout  object  constraction,  the  shape  morphism  aBi:GA->GBi  in  Figure  3-4 
induces  the  following  node  equivalent  groups;  {Bli},  {BI2},  {Ai,  BI3},  {A2,  BI4},  {A3,  BI5}.  For  shape 
morphism  CTb2:Ga-^Gb2,  the  induced  collection  of  node  equivalence  groups  is  {B2i},  {Ai,  B22}, 

{A2,  A3,  B23} ,  {B24} .  Combining  the  two  collections  of  node  equivalence  groups  by  merging  groups  with 
common  elements  yields  the  following:  {Bli},  {BI2},  {B2i},  {Aj,  BI3,  B22},  {A2,  A3,  BI4,  BI5,  B23}, 
{B24}.  These  equivalence  groups  are  labeled  Ci  through  Ce  respectively  in  the  pushout  object  Gc  in  Figure 


3-4. 


A  similar  process  Combines  the  induced  arrow  equivalence  groups  to  form  the  arrows  of  shape  Gc 


in  Figure  3-4.  The  functors  Obi’  and  aB2’  map  each  object  and  arrow  in  shape  categories  Gbi  and  Gb2 
(respectively)  into  the  equivalence  group  in  Gc  of  which  it  is  a  member. 

Minimality  of  object  Gr:  Assume  that  diere  exists  another  shape  category,  Gx,  that  forms  a  commuting 
square  widi  the  diagram  Gbi  <ibi—  Ga  -ctb2— >  Gb2-  Let  each  arc  and  node  of  shape  Gx  have  an  equivalence 

group  consisting  of  itself  and  the  arcs  and  nodes  of  the  shape  categories  Ga,  Gbi,  and  Gb2  that  are  mapped 
to  it  by  the  cocone  functors,  J4.:Ga-^Gx,  !B1:Gbi->Gx,  and  !B2:Gb2— ^’Gx- 

For  each  q  e  Objects(Gx),  ilx  ={  }'-'(«  I  “  ^  Objects(GA)  a  J4.(a)  =  q}  u 

a  e  Objects(GBi)  a  ®  1(a)  =  q} 
a  e  Objects(GB2)  a  lB2(a)  =  q} 

For  each/6  Objects(Gx),/x  ={/}'-'  I  g  e  Arrows(GA)  a  JA(g)  =  q)  u 

g  6  Arrows(GBi)  a  =  q} 
g  6  Arrows(GB2)  a  S2(g)  =  q} 

By  construction  of  shape  Gc,  the  equivalence  groups  associated  with  die  arcs  and  nodes  of  Gc,  and 
the  equivalent  groups  associated  with  the  nodes  and  arcs  of  shape  Gx,  the  following  two  predicates  will 
always  hold: 

For  each  qi  e  Objects(Gc)  there  exists  an  q2  e  Objects(Gx)  such  that  qic  £  qix. 
i.e.  the  equivalence  group  associated  with  q  1  is  a  subset  of  the  equivalence  group  associated  with  q2. 

For  each/i  e  Arrows(Gc)  there  exists  an/2  e  Arrows(Gx)  such  that/ic  ^fix 
i.e.  the  equivalence  group  associated  with/  is  a  subset  of  the  equivalence  group  associated  with/. 

This  subset  relationship  forms  the  basis  of  the  universal  arrow  Gc->Gx  drat  associates  a  Gx  node 


with  each  Gc  node  and  a  Gx  arc  with  each  Gc  arc.  A  Gc  arc  (node)  can  only  be  mapped  to  a  single  Gx  arc 
(node)  by  this  constraction  because  the  nodes  (arcs)  in  the  equivalence  group  associated  with  the  Gc  node 
(arc)  must  all  be  mapped  to  the  same  Gx  node  (arc)  for  Gx  to  be  part  of  a  commuting  diagram. 
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If  shape  Gx  contains  additional  arcs  and  nodes  (additional  “structure  )  not  mapped  to  by  the 
nodes  and  arcs  of  shape  categories  Ga,  Gbi?  and  Gb25  then  the  equivalence  group  names  of  these  additional 
arcs  and  nodes  will  contain  their  own  names  and  no  others  and  thus  will  not  be  mapped  to  by  any  nodes  and 
arcs  in  shape  Gc.  Several  Gc  arcs  and  nodes  could  be  mapped  to  the  same  Gx  arcs  and  nodes  if  shape  Gx 
has  “collapsed”  more  of  its  shape  than  is  necessary  as  indicated  by  object  Ga  and  morphism  Obi  and  032- 

The  mapping  between  Gc  and  Gx  must  form  a  shape  morphism  because  the  situation  of  an  arc  and 
its  adjacent  nodes  in  shape  Gc  being  mapped  to  an  arc  and  non-adjacent  nodes  in  Gx  would  require  such  an 
occurrence  to  also  happen  between  object  Ga,  Gbi,  or  Gb2  and  object  Gx-  This  could  not  happen,  as  object 
Gx  is  assumed  to  be  part  of  a  commuting  diagram. 

Universal  arrow  completes  a  commuting  diagram:  The  arrow  Gc^Gx  is  part  of  a  commuting  diagram 
connecting  the  two  commuting  squares  as  the  equivalence  group  names  associated  with  the  arcs  and  arrows 
of  shape  Gc  must  be  a  subset  of  those  of  shape  Gx.  This  subset  relationship  indicates  that  the  mapping  of 
the  arcs  and  arrows  commute  in  the  context  of  the  larger  diagram. 

Universal  arrow  is  unique:  The  arrow  Gc->Gx  is  unique  as  a  different  arrow  between  the  objects  would 
necessarily  violate  the  subset  relationship  among  the  equivalence  group  names  and  therefore  would 

necessarily  not  be  part  of  a  commuting  diagram 

Intuitively  tiie  construction  of  shape  Gc  is  the  maximal  combined  shape  that  does  not  introduce 
additional  structure.  If  shape  Gx  has  more  structure  than  shape  Gc  then  there  is  a  unique  arrow  Gc^Gx  as 
shape  Gc  can  be  “embedded”  in  shape  Gx  by  not  mapping  Gc  nodes  and  arcs  to  those  extra  nodes  and  arcs 
in  Gx-  If  shape  Gx  combines  (“collapses”)  shapes  Gbi  and  Gb2  to  a  greater  degree  than  is  needed  based  on 
the  sharing  required  by  shape  Ga  then  shape  Gx  will  have  a  unique  arrow  to  it  from  shape  Gc  that  collapses 
those  same  nodes  and  arcs. 

Proposition  3.5,  The  category  of  shapes  is  cocomplete. 

Proof:  The  empty  shape  (no  nodes  or  arcs)  is  the  initial  object  in  the  category  of  shapes  as  it  has  a  unique 
arrow  mapping  its  nodes  and  arcs  (all  none  of  them)  to  the  nodes  and  arcs  of  any  other  shape.  Any 
category  that  has  an  initial  object  and  pushouts  for  all  diagrams  of  the  form  B  1<-A“->'B2  is  cocomplete 
[Gol84]. 
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3.2  The  Arrow  Category, 

The  arrow  category,  X"^,  of  category  X  is  used  in  this  thesis  to  express  die  property  that  the 
collection  of  X-arrows  making  up  a  morphism  between  diagrams  preserves  the  objects  and  arrows  of  the 
source  diagram  in  the  target  diagram.  The  material  in  this  section  supports  the  defiiution  of  a  diagram 
morphism  in  Section  3.3  and  the  definition  of  a  diagram  category  in  Section  3.3.3.  The  Source  and  Target 
functors  developed  in  Section  3.2.1  and  the  •  operation  in  Section  3.2.2  are  original  but  are  based  on 
similar  functors  and  a  similar  operation  presented  in  [SJ95]. 

An  arrow  category  [Gol84,  AHS90]  is  defined  over  an  existing  category  using  tire  arrows  of  that 
category  as  its  objects  and  pairs  of  anows  that  form  commuting  squares  as  its  arrows. 

Definition  3.6.  Given  a  category  X,  the  arrow  category  X'^  has  as  its  objects  all  of  the  arrows  of  category 
X,  i.e.  Objects(X^)  =  Arrows(X).  An  arrow  in  category  X"^  is  a  pair  of  arrows  of  category  X  that  form  a 
commutative  square  with  the  domain  and  codomain  objects  of  die  X”^-arrow,  i.e.  given  X  -objects  x;A— >11 
and_y:B— >V  an  X^  arrow  OL'jc—>y  is  a  pair  of  X-arrows  f  :A— >B  and  i:U— >V  such  that  the  resulting  square 
commutes  (See  Figure  3-5).  ^Note  diat  because  the  square  commutes  there  is  also  a  category  X"^  arrow 


Category  X  Category 

Figure  3-5.  Category  X  compared  with  the  arrow  category 

The  objects  and  anows  of  category  X“^  are  completely  defined  by  the  arrows  of  category  X,  hence 
the  name  X"*.  An  identity  arrow  in  X^  of  an  object  idp,  is  simply  the  pair  <  idp,,  idf,>.  Figure  3-6  depicts 
the  composition  of  arrows  in  X"^. 
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Category  X  Category  X-* 

Figure  3-6.  Sequential  composition  of  X”^  arrows 


3.2.1  Fimctors  Source  and  Target  over  the  arrow  category 

The  functors  Source-.X^-^X  and  Target:Xr*-^X  are  used  in  the  definition  of  a  morphism  between 
diagrams  in  Section  3.3. 

Definition  3.7.  Source  is  a  pair  of  functions  <  Sourceobjectj  Source >  that  map  category  X^  objects  and 

arrows  respectively  to  category  X  objects  and  arrows.  Sourceobject  ^nd  Sourcef^^,  are  defined  as  follows. 

for  each  a  e  X“^-objects  where  a:A->B,  So«rccobject(“)  =  A, 
for  each/  e  X“^-arrows,  where /=  </i,/  >,  SowrceAnowC/)  -fi- 

Definition  3.8.  Target  is  a  pair  of  functions  <  Targctobject.  Target >  that  map  category  X  objects  and 

arrows  respectively  to  category  X  objects  and  arrows.  Targcfobject  ^d  Targett^^  are  defined  as  follows. 

for  each  a  e  X^-objects  where  oc:A-^B,  7a/geiobject(a)  =  B, 
for  each  /  €  X'^-arrows,  where /=  <f\Ji  >,  Target =f2- 

Proposition  3.9.  Source  and  Target  are  functors. 

Proof:  An  identity  arrow  in  X^  for  object  a:A->U  is  the  X^  arrow  id  a.  a  -<  Wa,  idu  >->  oc.  Identity  arrows 
are  preserved  by  Source  and  Target  as  Source/^a,J}d^  is  the  category  X  identity  arrow  for  5oMrccobjeci(ct) 
and  Target t^Uida)  is  the  Category  X  identity  arrow  for  rargefobject(a)-  Functors  Source  and  Target 
preserve  the  composition  of  arrows  as  the  composition  of  X”*  arrows  g  ®/where/=  and 

g  =  <g,,  g2>  is  g  »/=  <gi  °/i,  gi  °^>  and  flierefore  Source(g)  »  Source(f)  =  Source(g  °f)  and 
Targeting)  °  Target{f)  =  Target(g  <>/). 
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3.2.2  Parallel  composition  operation,  •,  over  X’^-arrows 

Two  “sequential”  X'^-arrows  a:x->y  and  can  be  composed  using  die  category  X"^ 

composition  operation,  as  depicted  in  Figure  3-6.  The  •  operation  is  a  parallel  form  of  composition, 
illustrated  in  Figure  3-7.  The  •  operation  can  be  thought  of  as  the  sequential  composition  operation 
“rotated  90  degrees”;  i.e.  instead  of  Ihe  commuting  squares  being  one  after  the  other  (based  on  the  X^- 
arrow  direction),  they  are  side  by  side.  This  second  form  of  composition  is  used  in  Section  3.3.3  to  prove 
that  successive  diagram  moiphisms  compose. 

Deflnition  3.10.  The  parallel  conqjosition  operation,  •,  composes  two  X“^-arrows  a  and  p,  where 

TargeHa)  =  Source{\i),  to  a  third  X‘'-arrow  t  in  the  following  manner: 

T  =  <  Source{a),  Targel{\i)  > 
dom(r)  =  dom(p)  "x  dom(a),  and 
cod(T)  =  cod(p)  <>x  cod(a), 

where  “x  is  the  category  X  composition  operation. 


Category  X  Category  X“^ 

Figure  3-7.  Parallel  composition  of  X”*  arrows 

Using  the  •  operation  to  compose  two  X”^-aiTows,  ot  and  p,  where  Targst^ct)  —  Source(\^ 

composes  commuting  squares  in  die  underlying  category  X  to  form  a  new  X  arrow.  The  use  of  the 

sequential,  and  parallel,  •,  conqiosition  operations  satisfy  an  interchange  law  [SJ95].  given  four 
coihpatible  category  X”^  arrows  (otj,  0.2,  Pi,  P2)  as  depicted  on  the  left  in  Figure  3-8,  the  equation  on  the 
right  is  true. 
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(P2  •  Pi)  °  (“2  •  “l)  =  (P2  °  “2)  •  (Pi  ®  Ctl) 


Figure  3-8.  Interchange  law  of  sequential  and  parallel  composition  operations 


3 .3  The  Category  of  Diagrams 

This  section  formally  defines  the  notion  of  a  diagram  and  a  diagram  morphism  and  proves  that 
they  are  the  objects  and  arrows  of  a  category,  dX.  The  definition  of  a  diagram  morphism  and  the  definition 
of  category  dX  are  major  contributions  of  this  chapter  and  are  highly  important  to  this  dissertation  as  they 
are  die  fovmdation  for  the  rest  of  die  document. 

3.3.1  Diagrams 


Recall  diat  a  diagram  of  category  X  is  a  functor  D,  from  a  shape  category  G,  to  category  X, 
D:G^X  [AHS90],  See  Figure  3-9. 


a.  Shape  Category  b.  Select  objects  and  arrows  from  Category  X 

that  are  mapped  to  by  functor  D 

Figure  3-9.  A  diagram  is  a  functor  whose  domain  is  a  shape  category 
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DeHnition  3.11.  A  diagram  D  of  category  X  is  a  functor  <  Dobject,  Dattow  >-G  X  from  a  shape  category 
G  to  category  X  that  maps  the  nodes(objects)  and  arcs(arrows)  of  a  shape  category  G  to  selected  objects 
and  arrows  of  category  X. 

Notations  Given  a  diagram  D:G— >X,  and  given  a  node  (or  arc)  cc  in  G,  D((x)  is  the  associated  object  (or 

arrow)  in  X.  When  the  objects  and  arrows  of  D  are  referenced,  this  means  the  objects  and  arrows  of 
category  X  that  are  mapped  to  by  the  functor  D.  Thus  Objects(D)  =  {D(a)  |  a  e  Objects(G)}  and 
Arrows(D)  =  {D(/)  \f  e  Arrows(G)} 

Notation:  An  alternate  method  for  defining  a  diagram  exists  where  the  objects  and  arrows  of  the 

diagram  are  “directly”  listed  and  then  the  shape  and  functor  function  pairs  are  inferred  from  that  listing,  i.e. 

Diagram  D  in  Figure  3-5  is  defined  as  follows: 

Objects(D)  =  {A,  B,  C,  D} 

Arrows(D)  =  {/,  g,  K  h  } 

This  latter  definition  of  a  diagram  does  not  normally  allow  the  same  object  (or  arrow)  to  occur  in  a 
diagram  multiple  times,  as  the  notion  of  a  set  eliminates  duplicate  items.  However,  it  is  assumed  that  once 
a  diagram  is  defined,  or  given,  each  object  and  arrow  in  that  diagram  is  indexed  so  as  to  distinguish  it.  This 
indexing  enables  a  diagram  to  be  taken  apart  and  reformed  without  equating  what  would  ordinarily  be 
identical  objects  and  arrows. 

3.3.2  Diagram  morphisms 

The  definition  of  a  morphism  between  diagrams  is  based  on  a  “content  preserving”  arrow  category 
diagram  and  a  “structure-preserving”  shape  morphism.  Definition  3.12  and  Figure  3-10  are  based  on  the 
definition  of  diagram  refinement  as  presented  for  diagrams  in  category  Spec  in  [SJ95],  where  the  arrows 
between  diagrams  are  collections  of  compatible  interpretations  between  specifications. 

Definition  3.12.  Given  that  Di:Gi-^X  and  D2:G2-->X  are  arbitrary  diagrams  in  category  X  (i.e.  arbitrary 
functors  form  arbitrary  shape  categories  Gi  and  G2  to  category  X)  then  a  morphism  between  diagrams  is  a 
pair  of  functors  <8,  a>,  where  5:Gi->X^  is  a  diagram  in  category  X"^  and  a:Gi“->G2  is  a  shape  functor, 
such  that  the  Ca^diagram  (a  diagram  in  the  category  of  categories  and  the  functors  between  categories)  in 
Figure  3-10  commutes. 
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Figure  3-10.  The  deflning  diagram  for  a  morphism  between  diagrams 


Diagram  D,  in  Figure  3-10  is  a  functor  that  assigns  the  nodes  and  arcs  of  a  shape  category,  Gi,  to 
the  objects  and  arrows  of  the  target  category  X.  Diagram  D2  is  smularly  defined  over  a  shape  category  G2. 
Functor  a  represents  the  shape  morphism  between  shapes  Gi  and  G2  in  the  category  of  shapes  that  ensures 
that  the  shape  of  G2  is  compatible  with  shape  Gi.  For  example,  a  could  be  the  identity  functor  (Gi  =  G2),  cr 
could  be  a  monic  shape  embedding  where  sh^e  Gi  is  wholly  embedded  in  shape  G2  and  shape  G2  may 
contain  additional  nodes  and  arcs,  or  o  could  be  epic  in  which  case  part  of  Gi  s  shape  may  be  collapsed 
in  G2.  Thus,  via  the  top  and  side  arrows  in  Figure  3-10,  the  shape  of  the  category  X  diagram  Di  is 
compatible  with  that  of  the  category  X  diagram  D2. 

The  functor  (diagram)  8  assigns  the  nodes  and  arcs  of  shape  category  Gj  to  a  collection  of  X^ 
objects  and  arrows.  In  this  case  die  objects  of  8  are  the  needed  X-arrows  between  the  category  X  diagrams 
D,  and  D2,  as  category  X^-objects  are  category  X-arrows.  The  arrows  of  diagram  8  are  pairs  of  arrows  in 
category  X.  The  first  arrow  of  the  pair  is  in  diagram  Dj  and  the  second  arrow  is  in  diagram  D2  such  diat 
there  is  a  commuting  square  between  diagrams  Dj  and  D2.  For  the  diagram  in  Figure  3-10  to  commute, 
functor  (diagram)  Dj  must  be  equal  to  functor  (diagram)  Source  «  8,  and  functor  (diagram)  D2  ®  ct  must  be 
equal  to  functor  (diagram)  Target »  8.  This  latter  diagram  has  the  objects  and  arrows  of  diagram  D2  but  the 
shape  of  diagram  Dj  as  indicated  by  die  functor  composition  D2  °  <r.  The  objects  and  the  arrows  of 
diagram  Dj  are  preserved  in  diagram  D2,  because  the  entire  diagram  in  Figure  3-10  must  commute  for  die 
pair  <8,  o>  to  be  considered  a  valid  diagram  morphism  the  structure. 

As  an  example  of  a  diagram  morphism,  the  morphism  between  diagrams  from  Figure  3-1  is 
depicted  in  greater  detail  in  Figure  3-11,  where  the  underlying  structure  is  revealed.  While  the  functors  D,, 
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D2,  and  o  are  faithfully  rendered  in  Figure  3-11,  the  functors  8,  Source,  and  Target  (arrows  X<— X  -^X) 
are  not  because  the  arrows  between  die  X  diagrams  are  depicted  as  X-arrows  instead  of  as  a  diagram  of 
X”^-arrows. 


In  Figure  3-12  the  functors  5,  Source,  and  Target  are  accurately  portrayed.  The  restriction  of 
diagram  Dz,  Dj  »  a,  commutes  with  the  functor  Target  •  8.  The  arrows  that  connecting  diagram  D,  to 
diagram  Dz  o  ct  in  Figure  3-12  are  X-arrows,  die  same  arrows  as  those  that  connected  diagram  Di  to 
diagram  Dz  in  Figure  3-11. 
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3.3.3  The  Category  dA' 

The  diagrams  of  a  particular  category,  and  the  morphisms  between  those  diagrams,  are  diemselves 
the  objects  and  arrows  of  a  category. 

Proposition  3.13.  Given  a  category  X,  there  exists  a  category  of  diagrams  and  diagram  morphisms  of 
category  X  called  category  dX.  The  category  dX  objects  are  all  the  diagrams  of  category  X.  The  category 
dX  arrows  are  all  the  diagram  morphisms  of  the  category  X  diagrams. 

Proof:  Category  dX-arrows  compose  and  are  associative  because  (collections)  of  category  X  arrows 
compose  and  are  associative  and  shape  morphisms  compose  and  are  associative. 

Identity  Arrow:  The  identity  arrow,  Wd,  for  a  given  dX-object  D;G-4X,  is  Ihe  pair  of  functors  <id5,  ido^, 
where  idc  is  the  identity  shape  morphism  for  shape  category  G,  and  where  diagram  idi:G->Xr*  is  the 
following  pair  of  functions. 

8object(a)  =  {  idjxa)  I  oc  e  Objects(G)  },  i.e.  identity  arrows  of  the  X-objects  in  D, 

5Arrow(/)  =  {  <  D(/),  D(/)  >  |/e  Arrows(G)  }. 
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The  identity  dX-arrow  <5,  g>  defined  above  is  die  left  and  right  identity  for  the  composition 
operation  (see  below)  as  g  is  a  shape  category  identity  functor  and  the  nodes  in  diagram  8  that  connect 
diagram  D  with  itself  are  the  identity  arrows  of  the  X-objects  making  up  the  diagram. 


rnmpnsitirtn  of  arrows:  Successive  morphisms  between  diagrams  compose  (as  depicted  in  Figure  3-13) 
because  the  juxtaposition  of  two  Figure  3-10  diagrams  representing  the  corrqiosition  of  two  successive 
diagram  morphisms,  <8i,  Gi>  <>  <82,  G2>,  “compose”  as  depicted  in  Figure  3-14. 


In  Figure  3-14,  functors  Gi  and  G2  compose  to  form  a  single  shape  morphism,  G2  ®  Gi,  from  shape 
G,  to  shape  G3.  Functor  82 »  g,  restricts  the  shape  of  functor  82  to  that  of  shape  Gi.  (If  shape  G2  has 
additional  arcs  and  nodes  not  “covered”  by  Gj  then  diese  extra  nodes  and  arcs  are  removed.  If  some  of 
Gi’s  arcs  and  nodes  are  “collapsed”  in  their  mapping  to  shape  G2  then  these  arcs  and  nodes  are  “expanded” 
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in  the  diagram.)  For  an  example  of  a  shape  restriction,  compare  functor  (diagram)  D2  in  Figure  3-1 1  with 
functor  (diagram)  D2  ®  c  in  Figure  3-12.  Functors  82  °  <^1  and  5i,  which  are  category  XT^  diagrams,  are 
then  conqjosed  using  a  variation  of  the  parallel  composition  operation  of  category  X"^. 

The  parallel  composition  operation  •  in  X“^  (Definition  3.10)  can  be  “raised  to  an  operation  on 
diagrams  in  X^.  Given  diagram  functors  8a:G— ^X”^  and  8b:G->X“^,  where  Sourcei^^  =  Target{?>p)^  the 
“raised”  •  operation  composes  5a  and  5b  to  form  a  functor  5c«C->X'^  where  the  objects  in  5c  are  the 
composition  of  the  adjacent  objects  (X-arrows)  in  5a  and  5b  and  where  5owrce(8c)  =  Source{bp)  and 
Target{b(^  =  Target{h^.  (Given  a  commuting  diagram  as  depicted  with  solid  arrows  in  Figure  3-15,  the 
dashed  arrows  are  formed  by  the  •  operator  and  are  also  commuting  arrows  with  the  rest  of  the  diagram.) 


An  example  of  this  is  illustrated  in  Figure  3-16,  which  depicts  one  such  composition  from  the 
example  diagram  morphism  of  Figure  3-13.  The  •  operation  over  category  X  diagrams  is  merely  the 
union  of  the  •  operations  over  the  individual  adjacent  commuting  squares  making  up  the  X*^  diagrams. 

Because  functors  5,  and  (82  °  aO  in  Figure  3-14  have  the  same  shape  category,  Gi,  as  the  domain 
category  and  they  have  a  common  “codomain/domain”,  (Cod  «  81)  =  (Dom  o  82  o  (^i),  the  objects 
(X-arrows)  making  up  functors  81  and  (82  «  aO  can  be  individually  composed.  That  composition  also  has 
shape  Gi  and  is  expressed  as  (82  ®  Oi)  •  81,  i.e.  a  shape  restriction  (82  ®  cii)  followed  by  the  composition  of 
a  collection  of  compatible  commutative  squares  (composing  a  collection  of  pairs  of  arrows  in  X"^  with  the  • 
operation).  Thus  <  81,  ai  >  »  <  82,  a2  ^  (S2  ®  ^i)  •  ^2  ®  cri 
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Associativity  of  arrows:  The  proof  of  the  associativity  of  diagram  morphisms  relies  on  the  juxtaposition  of 
three  Figure  3-10  diagrams  as  depicted  in  Figure  3-17. 


The  proof  that  the  composition  of  diagram  morphisms  is  associative, 
i.e.  (<5i,  a,>  o  <82,  a2>)  °  <83,  a3>  =  <81,  a,>  «  (<82, 02>  °  <83,  Os>),  relies  on  the  associativity  of 
functors,  the  associativity  of  the  •  operation,  and  the  factoring  of  a  shape  “restriction”  over  a  •  operation. 


(<  5i,  Gi  >  o  <  82,  a2  >)  ®  <  83,  03  > 

<  (82  o  Gi)  *81,  G2  o  Gi  >  o  <  83,  G3  > 

<  (83  o  (G2  o  Gi))  •  ((82  ®  Gi)  •  81),  G3  o  G2  ®  Gi  > 

<  ((83  o  G2)  ®  Gi)  •  ((82  ®  Gi)  •  81),  G3  o  02  0  Gi  > 

<  (((83  o  02)  o  Gi)  •  (82  o  Gi))  •  81,  G3  o  02  ®  Gi  > 

<  ((((83  o  G2)  •  82)  o  Gi)  •  81),  G3  o  G2  ®  G,  > 

<  81,  Gi  >  ®  (<  (83  o  G2)  •  82,  G3  o  G2  >) 

<  81,  Gi  >  o  (<  82,  G2  >  ®  <  83,  G3  >) 


Given:  Left  associative  equation 
First  composition  of  arrows  in  dX 
Second  composition  of  arrows  in  dX 
Associativity  of  functor  composition,  <> 
Associativity  of  parallel  composition^^ 
Factoring  out  the  shape  restriction,  ot 
First  funkomposition  of  arrows  in  (DC 
Second  (im^comnosition  of  arrows  in  dX 


There  exists  a  diagram  category  dK  for  each  category  X  because  diagram  morphisms  between 
diagrams  of  a  category  X  compose  and  are  associative  and  there  exists  an  identity  diagram  morphism  for 
each  X  diagram. 
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3. 4  Partitioning  and  Flattening  Diagrams 


In  order  to  be  able  to  operate  freely  over  category  X  and  category  rfX,  the  relationships  that  exist 
between  the  two  categories  must  be  formalized.  The  relationships  defined  in  this  section  are  used  in 
Chapter  6  to  describe  the  representation  of  diagram  information. 

3. 4. 1  The  functor  Diagramize 

The  functor  DiagramizeCKr-xlK  takes  X-objects  to  “singleton”  X  diagrams  and  takes  X-arrows  to 
diagram  morphisms  between  die  singleton  diagrams. 

Definition  3.14.  Diagramize  is  the  pair  of  functions  <  Diagramizco^^cti  Diagramizep^irow^  X-objects 
and  X-arrows  respectively  to  c/X-objects  and  ^fX-arrows.  Diagramizeobject  Bnd  Diagramize are  defined 
as  follows: 

For  each  a  e  Objects(X),  DiagramizeobjcJ,^)  =  D:G->X, 
where  G  =  D(®)  =  E)(^)  “  ida. 

For  each /  e  Arrows(X),  Diagramize =  <5:G-^X'^,  a>, 
where  a  =  g  =  5(»)  =/,  5(13) 

Proposition  3.15.  Diagramize  is  a  functor  from  category  X  to  category  t/X. 

Proof;  Diagramize  preserves  identity  arrows  as  a  category  X  identity  arrow  A  “id->  A  (i.e.  idp)  becomes 
the  diagram  morphism  identity  arrow,  <5,  ->  >,  where  5(#)  =  id^  and  8(13)  =  {<  id^,  id^  >}• 

Diagramize  preserves  arrow  coiiq)ositions  as  all  of  the  resulting  diagram  morphisms  have  the  same  shape, 
thus  the  shape  morphism  component  of  a  diagram  composes.  Also  the  X  -objects  of 
diagram  8,  being  parallel  X-arrows,  compose  under  the  parallel  composition  operation,  •,  i.e. 
Diagramize{hr-^  «x  B— >C)  =  Diagramize{K'-^^&)  •  Diagramize(3—>C) 

3.4.2  The  functor  Colimit 

If  category  X  is  cocomplete  then  there  exists  a  functor,  Colimit:dX->X,  from  category  dX  to 
category  X  based  on  the  colimit  operation  on  diagrams  in  category  X. 

Definition  3.16.  Colimit  is  a  pair  of  functions  <  Colimitoby^,  Colimit/i^oy,  >  from  category  dX  objects  and 
arrows  respectively  to  category  X  objects  and  arrows.  ColimitQbjcct  Colimit^^j^yi^f  are  defined  as  follows 
(imder  the  assumption  that  category  X  is  cocomplete): 
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For  each  a  e  Objects(cK),  Co//mrYobject(“)  =  colimitx(a), 
where  colimitx  is  the  colimit  operation  of  category  X. 

For  each/ 6  Arrows(«?X),  Colimit is  the  universal  X-arrow  from  the  X-object 
Cb//ffH7objec.(dom(/))  to  the  X-object  Colimito^^coA{f)),  as  the  latter  object  has  a  cocone 
to  it  from  the  diagram  dom(/)  (as  depicted  in  Figure  3-18). 


Figure  3-18.  Existence  and  uniqueness  of  an  X  arrow  induced  by  the  Coliinit:dK-*X  functor 
Proposition  3.17.  Colimit  is  a  functor  from  category  dX  to  category  X. 

Proof:  Identity  arrows  are  preserved  by  Colimit  as  the  universal  arrow  from  an  object  to  itself  is  the 
identity  arrow.  Arrow  composition  is  also  preserved  as  two  successive  diagram  morphisms  Di->D2-^D3 
along  with  their  colimit  objects  can  be  viewed  as  a  large  category  X  diagram,  and  in  that  category  die 
cocone  morphisms  and  the  universal  arrows  between  the  colimit  objects  are  all  commuting  arrows. 

Functors  Diagramize  and  Colimit  have  an  interesting  relationship  when  viewed  in  conjunction 
with  diagrams  in  category  X  and  diagrams  in  category  dX.  The  two  functors  enable  diagrams  in  one 
category  to  be  viewed  as  diagrams  in  the  other  category.  Figure  3-19  depicts  a  specific  example  of  a 
category  X  diagram  and  a  category  dX  diagram  related  by  functors  Diagramize  and  Colimit.  The  two 
functors  are  not  inverses  as  Diagramize  is  a  monic  functor  whereas  Colimit  is  not,  i.e.  there  may  be  many 
category  dX  diagrams  that  die  Colimit  functor  maps  to  the  same  elements  within  category  X.  Note  that  in 
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Figure  3-19,  functor  D  is  a  category  X  diagram  and  functor  D  is  a  category  dX  diagram  and  fliat 
domain(D)  =  domain(2)). 


Figure  3-19.  Relationship  between  functors  Diagramize  and  Colimit 


3.4.3  Flattening  a  category  dX  diagram 

Any  category  dX  diagram  can  be  viewed  as  a  category  X  diagram  by  removing  the  additional 
structure  associated  with  the  category  dX  objects  and  arrows  and  adding  in  the  additional  arrows  and  arrow 
compositions  induced  by  the  diagram  morphisms.  Thus,  for  example,  the  category  dX  diagram 
Dj^D2-»D3  from  Figure  3-13  can  be  viewed  as  the  category  X  diagram  as  depicted  in  Figure  3-20.  Note 
that  Figure  3-20  does  not  depict  any  identity  arrows  or  arrow  compositions  in  order  to  keep  the  diagram 
simple.  The  function  Flatten  is  defined  to  return  a  category  X  diagram  based  on  the  category  X  objects  and 
arrows  underlying  the  diagrams  and  diagram  morphisms  in  a  given  category  dX  diagram. 


Figure  3-20.  Flattening  a  category  dX  diagram 
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Definition  3.18.  Flatten  is  a  function  from  category  dK  diagrams  to  category  X  diagrams  defined  as 
follows: 

Flatten(D)  =  D:G-»X 

Let  D:Go->ffX  hez.dK  diagram, 

Let  D,:G,-^X  be  dK  objects  of  V,  i.e.  D,  =  I>(a)  for  some  a  e  Objects(Go) 

Let  <  hj,  Oj  >hedK  arrows  of  D,  i.e.  <  ,Gj  >  =  D(/)  for  some/e  Arrows(Go) 

Shape  G  is  defined  as  follows: 

Objects(G)  =  U  Objects(G/), 

i.e.  a  union  of  the  nodes  associated  with  each  shape  G/  of  a  diagram  D/  of  !D. 

Arrows(G)  =  U  Arrows(G/)  u  {a— >aj(a)  |  a  e  Objects(dom(ay))} 
and  closed  xmder  composition 

i.e.  a  union  of  the  arrows  associated  with  each  shape  G/  of  a  diagram  D/  of  D 
unioned  with  arrows  between  the  nodes  of  different  diagrams  constructed  based  on  the  shape 
moiphisms  (oj)  between  the  diagrams  of  D,  and  then  the  result  closed  under  composition. 

Functor  DiG-^X  is  the  pair  of  functions,  <  Dobject>  D Arrow  ^  defined  as  follows: 

For  each  a  e  Objects(G),  Dobject((x)  =  D^a)  for  an  a  that  originated  in  G, 

For  each  /  e  Arrows(G) 

DattowC/)  ==  D/(/)  for  an / that  originated  from  G, 

5f(dom(/) )  for  an / that  originated  as  an  arrow  between  the  G/  shapes 
Daitow(/i  )  °  DAirow(/2  )  for  an/ that  originated  as  the  composition/,  o/ 

3,4.4  Partitions  of  a  category  X  diagram 

Informally,  the  act  of  partitioning  induces  a  category  dX  diagram  made  up  of  the  objects  and 
arrows  of  a  given  category  X  diagram.  Flattening  the  resulting  partition  (the  category  dX  diagram)  must 
result  in  the  original  category  X  diagram  from  which  it  was  derived. 

At  the  top  of  Figure  3-21  is  a  category  X  diagram,  D:G-^X.  This  category  X  diagram  is 
partitioned  into  four  different  category  dX  diagrams.  The  shapes  Ga  through  Gj  and  the  morphisms  to  them 
from  shape  G  indicate  how  the  category  X  diagram  D  can  be  partitioned  into  category  dX  diagrams.  In 
Figure  3-2 1(a),  diagram  D  is  partitioned  as  a  imit  into  a  singleton  dX  diagram  ©a-  This  singleton  dX 
diagram  is  called  the  trivial  partition  of  the  X  diagram.  In  Figure  3 -2 1(b),  each  individual  specification  in 
diagram  D  is  viewed  as  a  dX  object  and  the  arrows  in  diagram  D  become  diagram  morphisms  between 
those  dX  objects  as  depicted  in  the  dX  diagram  ©b-  This  is  called  the  maximal  partition  of  the  X  diagram 
and  this  maximal  partition  can  also  be  constructed  using  the  functor  Diagramize  defined  in  Section  3.4.1. 
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Every  X  diagram  can  be  interpreted  as  a  dX  diagram  using  either  a  trivial  partition  or  a  maximal  partition 
of  the  X  diagram.  If  the  X  diagram  is  itself  a  singleton  then  the  trivial  and  maximal  partitions  in  dX  are 
identical.  There  may  be  other  ways  to  partition  any  given  X  diagram  into  a  dX  diagram  such  as  depicted  in 
Figure  3-21(c)  and  Figure  3-21(d)  for  the  given  diagram  D.  Arbitrary  “partitions”  of  an  X  diagram  into 
collections  of  objects  and  arrows  may  not  result  in  a  rfX  diagram  though  as  it  may  not  be  possible  to  form  a 


diagram  morphism  between  the  partition  elements. 


Figure  3-21.  Partitioning  a  category  X  diagram  into  different  category  dX  diagrams 


Informally,  a  partition  morphism  (such  as  the  shape  morphisms  (^3,  0^^,  Cc  aa  in  Figure  3-21)  is 
used  to  break  up  a  category  X  diagram  into  sub-diagrams  such  that  well  formed  diagram  morphisms  exist 
between  the  sub-diagrams.  A  partition  morphism  is  a  shape  epimorphism  with  additional  properties  related 
to  the  arrows  between  the  objects  making  up  the  partition  elements.  A  partition  morphism  indicates  which 
category  dX  diagram  to  derive  from  a  category  X  diagram,  the  trivial  partition,  the  maximal  partition,  or 
some  other  partition.  Given  a  diagram  D:G^X,  the  trivial  partition,  Figure  3-2 1(a),  is  formed  by  the 
partition  morphism  which  indicates  that  all  of  the  objects  and  arrows  in  of  diagram  D  should  form 
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a  single  dX.  diagram.  The  maximal  partition.  Figure  3-21(b),  is  formed  by  the  partition  morphism  Ob  =  ido 
(the  identity  shape  morphism),  which  indicates  that  each  individual  X  object  of  diagram  D  should  form  its 
own  dX.  diagram. 

Deflnition  3.19.  A  Partition  morphism  is  an  epimorphism  between  two  shapes,  a:Gi->G2,  that  satisfies  the 
following  four  predicates: 

1) -  Each  collapsed  source  node  has  an  arrow  to  a  collapsed  target  node 

For  each  non-identity  arrow  /  e  Arrows(G2), 

Let  Collapsed-source-nodes  =  {a  |  a  e  Objects(Gi)  and  a(a)  =  dom(/) }. 

For  each  a  e  Collapsed-source-nodes 

there  must  exist  a  a-^P  e  Arrows(Gi) 
such  that  a(a->P)  =/ 

2) -  Each  collapsed  source  arrow  has  an  associated  collapsed  target  arrow 

For  each  non-identity  arrow /  e  Arrows(G2), 

Let  Collapsed-source-arrows  =  {g  |  g  e  Arrows(Gi)  and  a(g)  =  id^omif) 

For  each  g  e  Collapsed-source-arrows 

there  must  exist  a  a->P  e  Arrows(Gi) 
such  that  c(a^P)  =  iV/cod(/) 

and  there  exist  arrows  dom(g)->a,  cod(g)->p  e  Arrows(Gi) 

3) -  Collapsed  arrows  with  the  same  domain  node  must  have  distinct  codomain  nodes 

For  each  non-identity  arrow /  e  Arrows(G2), 
for  each  distinct  h,  i  e  Arrows(Gi), 
where  o{h)  =/  a  cy(  i  )  =/  a  dom{h)  —  dom(z), 
it  must  be  the  case  that  cod{h)  ^  cod(0- 

4) -  Collapsed  arrows  with  the  same  domain  node  must  have  connected  codomain  nodes 

For  each  non-identity  arrow  /  e  Arrows(G2), 
for  each  distinct  A,  i  €  Airows(Gi), 
where  a(  ^  )  =/ a  a(  / )  =/a  dom(/r)  =  dom(i), 

it  must  be  the  case  that  there  exists  an  arrow  g:cod(A)->cod(0  e  Arrows(Gi)  or 

an  arrow  g:cod{i)->cod{h)  e  Arrows(Gi) 

For  a  given  diagram  D:Gi^X  and  a  partition  morphism  cy:Gi— >G2,  the  four  predicates  in 
Definition  3.19  are  necessary  to  ensure  that  the  objects  and  arrows  in  G2  induce  a  dX  diagram  that  is  based 
on  diagram  D.  These  predicates  are  necessary  to  indicate  a  partition  but  not  sufficient  as  the  commutative 
nature  of  a  diagram  cannot  be  stated  using  only  the  shape  of  a  diagram. 

Figure  3-22  depicts  examples  of  shape  epimorphisms  that  are  partition  morphisms.  Each  partition 
morphism  a:Gi“->G2  in  Figure  3-22  can  be  used  to  induce  a  diagram,  G3,  in  the  category  of  shapes.  The 
induced  diagram  G3  has  shape  G2  but  its  “contents”  are  based  on  shape  Gi.  Essentially,  any  category  X 
diagram  D:Gi->X  (where  Gi  is  any  of  the  shapes  in  Figure  3-22)  can  be  partitioned  into  a  dX  diagram  with 
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shape  G2  and  whose  contents  are  reflected  by  the  mapping  from  the  shape  Gi  contents  to  the  shape  G3 
contents. 


Figure  3-22.  Shape  epimorphisms  that  are  partition  morphisms 


In  contrast  to  Figure  3-22,  each  shape  epimorphism  in  Figure  3-23  violates  one  or  more  of  the 
predicates  in  Definition  3.19  and  therefore  is  not  partition  morphism.  In  each  case  the  violation  indicates 
that  a  diagram  G3  in  the  category  of  shapes  cannot  be  induced  because  either  there  does  not  exist  an  arrow 
that  can  be  used  for  a  diagram  morphism  or  there  exists  too  many  arrows  to  choose  from  and  the  choices 
are  mutually  exclusive. 

For  example,  shape  morphisms  Ca  hi  Figure  3-23  violates  predicate  (1).  A  required  arrow  for  a 
diagram  morphism  does  not  exist  in  shape  Gi,  and  therefore  the  shape  of  a  diagram  morphism  cannot  be 
induced  by  Ga,  (compare  Figure  3-22(a)  with  Figure  3-23(a)).  Shape  morphism  at,  Figure  3-23(b),  violates 
predicate  (3).  Only  one  of  the  two  arrows  can  be  used  for  the  shape  of  the  diagram  morphism  and  the 
choice  is  mutually  exclusive  (assuming  that  the  imderlying  arrows  are  not  the  same  arrow).  Shape 
morphisms  Cc  and  violate  predicate  (4).  More  than  one  arrow  choice  exists  for  a  diagram  morphism  and 
the  choices  are  mutually  exclusive.  Shape  morphism  ae  violates  predicates  (1)  and  (4).  Shape  morphism  Cf 
violates  predicate  (2)  as  there  does  not  exist  a  target  arrow  associated  with  the  indicated  source  arrow  and 
therefore  a  commuting  square  in  the  underlying  category  could  never  be  formed.  A  diagram  D:Gi-»X  with 
any  shape  Gi  in  Figure  3-23  cannot  use  the  associated  shape  morphism  to  induce  a  dX  diagram  shape.  In 
every  case  either  the  required  diagram  morphism  cannot  be  formed,  or  if  formed  with  an  arbitrary  choice 
some  of  the  structure  from  the  category  X  diagram  will  be  lost. 
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Figure  3-23.  Shape  epimorphisms  that  are  #ii>t  partition  morphisms 


Note  that  shape  morphism  Ob  in  Figure  3-22(b)  also  appears  to  have  more  than  one  choice  for  the 
diagram  morphism  in  shape  G3.  However,  because  the  codomain  nodes  involved  in  the  choice  are 
connected,  i.e.  predicate  (4),  the  arrow  choice  that  was  not  taken  can  be  derived,  by  arrow  composition, 
from  the  arrow  choice  that  was  taken.  In  Figure  3-22(b),  even  though  one  of  the  arrows  was  not  used,  it 
can  be  recovered.  For  the  case  depicted  in  Figure  3-23(c),  deriving  the  arrow  choice  lhat  was  not  taken  is 
not  possible  as  predicate  (4)  is  violated  (the  target  nodes  are  not  connected  via  an  arrow)  and  therefore 
arrow  composition  cannot  be  used  to  recover  the  arrow  choice  that  was  not  taken. 

Deflnition  3.20.  The  (partial)  fimction  Partition  takes  a  category  X  diagram  D:G“->X  and  a  partition 
morphism  a:G->Go  and  returns  a  category  dX  diagram,  D:Go->rfX,  called  partition  of  diagram  D 
defined  as  follows:  Partition(D,  a)  —  2)  iff  Flatten(2))  —  D. 
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The  function  partition  is  partial  as  it  may  not  be  defined  if  D  is  not  a  commuting  diagram.  As  an 
example,  in  Figure  3-24,  if  diagram  D:Gi-“>X  is  a  commuting  diagram  then  diagram  ViGs-^dX  is  defined. 
If  diagram  D  is  not  a  commuting  diagram  then  diagram  'D  is  not  defined  as  the  X-arrows  making  up  the 
diagram  morphism  2)  cannot  form  a  commuting  square.  Not  all  non-commuting  diagrams  have  such  a 
problem. 


Commutes  only  if 
diagram  D  commutes 


Figure  3-24.  The  dX  diagram  V  induced  by  a  partition  morphism  a  may  not  exist 


The  dX  diagram  returned  by  the  partition  function  may  be  ambiguous  if  the  non-commuting 
arrows  are  within  a  dX  object  and  not  between  the  objects.  In  Figure  3-25,  if  the  A— arrow  forms  a 
commuting  square  with  both  of  the  C->D  arrows  then  there  exist  two  possible  dX  diagrams  for  the  given 
partition  morphism.  The  “correct”  choice  of  C-">D  arrow  to  pair  with  the  A— arrow  cannot  be  induced 
fi:om  the  partition  morphism  alone.  Either  or  both  choices  may  be  correct  but  the  partition  morphism 
cannot  be  used  to  indicate  which  C“>D  arrow  should  be  used,  hence  the  ambiguity.  Not  all  non¬ 
commuting  diagrams  have  this  problem  either. 
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Figure  3-25.  The  <fX  diagram  D  induced  by  a  partition  morphism  0  may  be  ambiguous 

Given  a  category  X  Hiagram  D:G^X  and  a  partition  morphism  a;G-)'Go,  the  category  dX 
diagram  D'.Go-^dX  can  be  constmcted  as  follows; 

For  each  Oj  e  Objects(Go),  let  the  dX  object  Di:Gi-»X,  be  induced  by  die  follovraig  assignments: 
Objects(Gi)  =  { Tj  1 11  e  Objects(G)  a  0(r|)  =  ttj }, 
i.e.  all  G  nodes  mapped  to  node  Oj  in  Go 
Arrows(Gi)  =  {/|/e  Arrows(G)  a  o(f)  =  idm  }, 

i.e.  all  G  arrows  mapped  to  the  identity  arrow  of  node  Ui  in  Go 

Note  that  for  each  t|  6  Objects(Gi)  there  exists  an  associated  t)  e  Objects(G) 

and  for  each / e  Arrows(Gi)  there  exists  an  associated /e  Arrows(Gi). 

Let  functor  Di  be  die  pair  of  functions  <  Di.objects)  Di.An»ws  >  defined  as  follows 
For  each  i]  e  Objects(Gi),  Di.objects(T|)  =  D(t|) 

For  each /  e  Arrows(Gi),  Di.Am)ws(/)  =  D(/) 

Objects(D)  =  {Dj},  i.e.  for  each  ai  e  Objects(Go),  ©(aj)  =  Di:Gi->X. 

For  each  jj  €  Arrows(Go), 

let  the  dX  Arrow  T>{fj)  =  <8j.  0j>:Dm->DB, 
where  D„;G„-^X  =  D(dom(^)) 
and  Dn:G„-^X  =  D(cod(^)), 
be  computed  as  follows: 
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For  each  node  t|  g  Objects(Gm), 
letCj(T])  =  v 

where  t1“>v  g  Arrows(G)  a  a(ri->v)  = 
and  where  for  all  a  g  Objects(Gn), 

where  rj-^a  g  Arrows(G)  and  G(r\-^CL) 
there  exists  an  arrow  v-^a  g  Arrows(G) 

Let  5j(Ti)  =  D(ii^v) 

Note  that  the  shape  arrow  ri“>v  must  exist  because  of  predicate  (1), 
the  arrow  Ti^v  is  unique  because  of  predicate  (3), 

and  the  shape  arrows  v— >a  must  exist  because  of  predicate  (4)  from  Definition  3.19. 

For  each  arc  g  g  Arrows(Gm), 

let  5j(g)  be  the  pair  of  X  arrows  <  Dni(g),  Dn(g’)  > 
where  g’  is  the  arc  aj(dom(g))“->aj(cod(g)) 
such  that  category  X  arrows  DmCgi  Dn(g’)5  8j(dom(g)),  8j(cod(g)) 
form  a  commuting  square 

Letaj(g)  =  g’ 

Note  that  an  arc  g’  is  guaranteed  to  exist  for  each  arc  g  because  of  predicate  (2). 

If  a  commuting  square  caimot  be  found  then  partition  is  imdefined  (see  Figure  3-24) 

If  multiple  commuting  squares  are  defined  then  the  dX  diagram  returned  by  the 
construction  is  arbitrary  (see  Figure  3-25). 

Operations  Flatten  and  Partition  have  a  relationship  similar  to  that  of  functor  Diagramize  and 
Colimit.  Flatten  takes  category  dX  diagrams  to  category  X  diagrams  and  Partition  does  the  reverse.  Every 
category  dX  diagram  has  only  one  X  diagram  to  which  it  will  flatten,  whereas  every  category  X  diagram 
may  have  more  than  one  category  dX  diagram  to  which  it  will  partition. 

3. 5  Operations  over  Diagrams 

In  order  to  work  with  category  X  diagrams  on  a  higher  level  of  abstraction  there  needs  to  exist  a 
core  set  of  operations  for  creating,  combining  and  manipulating  category  X  diagrams  instead  of  just 
constructing  them  out  of  a  collection  of  X-objects  and  X-arrows.  This  section  defines  the  concept  of  a 
diagram  extension  as  well  as  operations  for  joining  and  folding  diagrams.  This  section  also  defines  the 
notion  of  a  parameterized  diagram  and  an  instantiation  of  a  parameterized  diagram.  Together  these 
operations  are  used  to  define  the  semantics  of  the  diagram  statement  syntax  presented  in  Chapter  5,  which 
is  a  higher-level  syntax  for  creating  complex  diagrams  by  building  upon  smaller  component  diagrams. 
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3.5.1  Extending  a  diagram 


Extending  a  category  X  diagram  involves  adding  additional  nodes  and  arcs  to  a  diagram  while 
leaving  die  original  nodes  and  arcs  and  their  associated  category  X  objects  and  arrows  intact, 

DeHnition  3.21.  An  extension  morphism  m  category  rfX  is  a  diagram  monomorphism,  <5,  a>:Di->D2,  that 
satisfies  die  following  predicate:  D2  ®  a  =  Di. 


Figure  3-26.  Definition  of  a  diagram  extension 


Notation:  Diagram  D2  is  referred  to  as  an  extension  of  diagram  Di.  In  an  extension  morphism 
<5,  a>:Di->D2,  Objects(5)  =  {id^  |  a  g  Objects(D)}  and  Arrows(5)  =  {<//>  1/e  Arrows(D)},  i.e.  the 
diagram  5  objects  are  the  identity  arrows  for  all  of  the  objects  in  diagram  D  and  the  diagram  6  arrows  are 
all  of  the  pairs  of  arrows  in  diagram  D.  The  two  diagrams  in  Figure  3-26  are  equivalent  because  8  is 
entirely  determined  by  the  source  diagram  D  and  is  independent  of  the  extension;  therefore  the  diagram  on 
the  right  commutes. 

3.5.2  Joining  diagrams 

The  ultimate  form  of  diagram  composition  is  the  colimit  operation  of  category  rfX  (Section  3.6) 
that  can  combine  an  arbitrary  diagram  of  diagrams  into  a  new  diagram.  A  less  powerful  form  of 
composition,  actually  a  special  case  of  the  colimit  operation,  merely  umtes  unrelated  diagrams  into  a  single 
unified  diagram.  Any  number  of  diagrams  can  be  joined  together  by  taking  the  disjoint  imion  of  their 
shapes  and  underlying  X-objects  and  X-arrows. 

Definition  3.22.  The  operation  Jbm  is  a  function  from  a  collection  of  ^/X  objects,  {Di,  D2, ...  Dn},  to  a  f/X 

object  T>  defined  as  follows: 

Join(Di,  D2, . . .  D„)  =  Flatten(23), 

where  Objects(2J)  =  {D,  |  0  <  i  <  n  }  and 
Arrows(2))  =  {  |  0  <  i  <  n  } 


The  join  operation  is  a  special  case  of  the  coliniit  operation  of  category  rfX  as  the  collection  of 
objects  D|  form  a  category  t/X  diagram  T)  with  no  arrows  between  the  objects.  The  join  operation  induces 
an  extension  morphism  from  each  component  diagram,  D/,  to  the  “joined”  diagram,  ® . 

3.5.3  Folding  a  diagram 

The  fold  operation  combines  the  indicated  nodes  and  arcs  of  a  category  X  diagram  when  the 
underlying  associated  X-objects  and  X-arrows  of  the  indicated  nodes  and  arcs  are  the  same  X-objects  and 
X-arrows. 

Deflnition  3.23.  The  operation/oW  is  a  function  from  a  category  X  diagram,  Di:Gi*^X,  and  a  shape 
epimorphism  a:Gi^G2  to  a  category  X  diagram  D2:G2->X,  defined  by  the  commuting  diagram  in  Figure 
3-27.  The  fold  operation  fold(D:G->‘X,  a)  is  defined  whenever  a  is  an  epimorphism  that  satisfies  the 
following  properties: 

For  each  a,  P  e  Objects(G),  where  a(a)  =  cy(p), 

D(a)  =  D(p) 

For  each /,  g  e  Arrows(G),  where  o(/)  -  a(  g ), 

D(/)  =  D(g). 


Figure  3-27.  Definition  of  fold  operation 

An  example  of  a  fold  operation,  fold(Di,  <  <t  combing  nodes  3  and  5  >),  is  depicted  in  Figure 
3-28.  The  nodes  labeled  3  and  5  have  the  same  underlying  category  X-object,  C,  and  therefore  the  fold 
operation  is  defined  over  the  given  inputs.  A  different  a  could  combine  nodes  1  and  2  with  or  without  also 
combining  the  arcs  labeled  a  and  p. 
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3.5.4  Diagram  parameterization 

An  extension  morphism  does  not  limit  or  direct  how  a  diagram  can  be  extended.  The  concept  of 
parameterization  controls  or  guides  the  possible  extensions  of  a  diagram  when  coupled  witii  a  suitable  form 
of  instantiation. 

Definition  3.24.  A  parameterized  diagram  is  a  pair  <D,  a>  where  D  is  a  category  X  diagram  D:G->X  and 
where  a  is  a  shape  monomorphism  a:G->G’. 

G - G’ 

D 

X 

Figure  3-29.  Definition  of  a  parameterized  diagram 

One  can  view  a  parameterized  diagram  as  having  a  fixed  part  and  a  variable  part.  The  fixed  part  is 
the  shape  G,  the  variable  part  is  the  part  of  shape  G’  that  is  not  covered  by  shape  G.  Figure  3-30  depicts  a 
simple  parameterized  diagram,  <D:G— >X,  a:G— >G’>,  where  only  one  node  in  G  (and  the  accompanying 
arrow  to  that  node  and  identity  arrow  for  that  node)  is  uncovered.  Object  A  is  called  the  formal  parameter 
and  object  B  is  called  the  body. 
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Figure  3-30.  Example  parameterized  diagram 


3.5.5  The  “shape”  of  a  parameterized  diagram 

It  can  be  argued  that  the  expressive  power  of  parameterized  diagrams  comes  from  the  difference 
between  shapes  G  and  G’  and  not  the  underlying  assignment  of  shape  G  to  category  X  objects  and  arrows. 
Given  a  parameterized  diagram  <  D:G^X,  a:G-^G’  >,  shape  G  represents  the  underlying  fixed  objects 
and  arrows  from  category  X,  and  the  parts  of  shape  G’  not  covered  by  shape  G  represent  the 
variable/unknown/parameterized  objects  and  arrows  from  category  X.  The  depiction  in  Figure  3-3 1 
captures  the  “interesting”  part  of  the  parameterized  diagram  from  Figure  3-30;  namely,  the  difference 
between  shapes  G  and  G’.  The  solid  circles  and  lines  represent  shape  G  and  the  fixed  or  known  category  X 
objects  and  arrows  and  the  dashed  circles  and  lines  represent  the  difference  between  shape  G  and  G’,  the 
parameterized  part.  Shape  G’  can  always  be  indicated  this  way  as  a:G->G’  is  a  monomorphism. 


Figure  3-31.  Underlying  “shape”  of  the  example  parameterized  diagram 
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3.5.6  Diagram  instantiation 

Instantiating  a  parameterized  diagram  involves  “fixing”  the  variable  part  while  leaving  the  fixed 
part  alone. 

Definition  3.25.  An  instantiation  of  a  parameterized  category  X  diagram  <D:G^X,  a:G->G’>  is  a 
category  X  diagram  D’:G’->X  such  that  there  exists  an  extension  morphism/ :D-^D’. 

An  instantiation  of  a  parameterized  diagram  <D:G-^X,  a:G->G’>  is  an  extension  diagram  of  D 
with  shape  G’,  see  Figure  3-32.  One  can  think  of  diagram  D’  as  diagram  D  with  additional  arcs  and  nodes 
(and  category  X  objects  and  arrows)  “added  on”  to  diagram  D  such  that  it  has  the  shape  G  . 


Figure  3-32.  Instantiation  of  a  parameterized  diagram 


3.5.7  Analysis  of  parameterized  diagrams 

The  notion  of  a  parameterized  diagram,  <  D,  cj  >,  places  no  restrictions  on  the  relationship 
between  the  known  and  unknown  parts.  For  example,  an  unknown  node  could  be  the  source  of  an 
unknown  arrow  to  a  known  target  or  it  could  be  the  target  of  unknown  arrows  from  a  known  source. 

During  instantiation  the  unknown  node  (and  arrow)  must  be  associated  with  some  category  X  object  (and 
arrow);  thus  the  orientation  of  the  known  and  unknown  parts  is  critical  to  determining  which  X-objects  and 
X-arrows  (if  any)  can  be  used  to  instantiate  the  parameterized  diagram.  Table  3-1  depicts  a  selection  of 
differently  oriented  parameterized  diagrams  and  analyzes  them  as  to  the  “range”  of  X-objects  and  X-arrows 
that  can  be  used  to  instantiate  the  parameterized  diagram. 
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Parameterized  Diagram  (fragments)  and  their  meaning  in  terms  of  strict  instantiation 

Parameterized 

Diagram 

Meaning 

Solid  =  known/fixed 

dashed  =  unknown/variable/parameterized 

Can  be  (strictly)  instantiated  by... 

The  unknown  object  must  have  at  least  as 
much  structure  as  the  known  object. 

The  identity  arrow  and  the  given 
object  are  Ihe  lower  boimd,  no  upper 
bound 

The  unknown  object  must  have  at  least  as 
much  structure  as  the  objects  from  which  it 
has  arrows 

The  colimit  of  the  sub-diagram  whose 
sink  is  the  unknown  object  and  the 
associated  cocone  morphisms  are  the 
lower  boimd,  no  upper  bound 

The  unknown  diagram  must  have  at  least  as 
much  structure  as  the  known  diagram. 

Identity  arrows  and  the  given  objects 
(and  the  arrows  between  them)  serve 
as  the  lower  bound,  no  upper  bound, 
fixing  any  individual  unknown  object 
may  influence  the  other  objects 

(  ) 

There  are  no  restrictions  on  the  unknown 
object 

Any  object 

Cy-‘^Z) 

There  are  no  restrictions  on  the  unknown 
objects  or  the  arrow  between  them 

Any  arrow  and  associated  objects, 
fixing  either  object  alone  restricts  tbe 
remaining  object 

The  unknown  arrow  must  be  between  the  two 
known  objects 

There  may  be  no  instantiation 

The  unknown  object  can  have  at  most  as  much 
structure  as  the  known  object. 

The  empty  object  and  the  initial  arrow 
(if  any)  are  the  lower  bound,  the  given 
object  and  the  identity  arrow  are  the 
upper  bound 

The  unknown  object  must  have  at  least  as 
much  structure  as  the  known  “soiurce”  object 
and  no  more  structure  than  the  known  “target” 
object 

If  there  exists  an  arrow  between  the 
“source”  and  “target”  objects  then  the 
source  and  target  objects  form  the 
lower  and  upper  bounds  for  the 
unknown  object,  otherwise  there  is  no 
instantiation 

(' } — -► ... 

The  unknown  object  must  (collectively)  have 
no  more  structure  than  each  individual  object 
to  which  it  has  an  arrow 

The  initial  object  and  the  initial  arrow 
(if  they  exist)  are  the  lower  bound,  the 
limit  (if  it  exists)  of  the  diagram  whose 
source  is  the  unknown  object  and  the 
associated  cone  arrows  are  the  upper 
bound. 

/  "> 

The  unknown  objects  are  interdependent  in 
that  instantiating  either  may  influence  the 
structure  of  the  other 

Fixing  either  object  may  influence  the 
other 

Table  3-1.  Analysis  of  parameterized  diagram  shapes 
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In  Table  3-1  the  first  three  rows  are  lower  bound  parameterizations  where  the  unknown  part  is 
required  to  have  an  arrow  to  it  from  the  known  part  and  not  vice  versa.  The  second  part  of  the  table,  after 
the  break,  contains  more  diverse  notions  of  parameterization,  including  those  where  the  known  parts  play 
the  role  of  an  upper  bound  on  the  unknown  parts  instead  of  as  a  lower  bound.  In  the  syntax  to  be  developed 
in  Chapter  5,  only  the  lower  bound  form  of  parameterization  is  used,  i.e.  where  the  “formal  parameter”  part 
places  a  requirement  on  the  “actual  parameter”  part. 

5. 6  Colimits  in  the  Category  of  Diagrams 

In  this  section  a  colimit  operation  over  category  dX  diagrams  is  developed.  This  operation  enables 
category  dX  diagrams  (diagrams  of  diagrams  of  category  X)  to  be  combined  in  a  way  that  preserves  both 
the  content  and  the  structure  of  the  underlying  category  X  diagrams  in  a  minimal  fashion.  This  operation  is 
used  in  Chapter  6  to  conqjose  and  apply  design  information. 

The  sub-sections  of  this  section  are  as  follow:  Section  1  defines  an  operation  over  pushout 
diagrams  of  category  <fX.  Section  2  contains  an  example  of  the  pushout  operation  in  use.  Section  3  proves 
that  the  operation  defined  in  Section  1  is  a  is  a  pushout  operation  for  select  dX  diagrams.  Section  4 
contains  a  proof  that  category  dX  has  colimits  for  select  diagrams,  and  Section  5  contains  a  direction  for 
extending  the  proof  of  colimits  to  encompass  all  diagrams  of  category  dX, 

3.6. 1  The  Pushout  operation  in  category  dX 

A  pushout  (Definition  A.  15)  in  category  dX,  depicted  in  Figure  3-33(a)  actually  has  the 
underlying  structure  depicted  in  Figure  3-33(b). 

Deflnition  3.26.  Given  a  category  dX  diagram  Dbi^Da‘^Db2  and  given  that  category  X  is  cocomplete,  an 
object  Dc  and  commuting  arrows  Dbi->Dc<“Db2  can  always  be  determined  using  the  following  steps: 

(1)  Determine  the  shape  diagram,  Gc,  along  with  functors  and  aB2’. 

(2)  Create  the  functor  Dc:Gc-->X  by  labeling  nodes  and  arcs  of  shape  Gc  with  category  X 
objects  and  arrows. 

(3)  Determine  functors  8bi’  and  8b2’  in  the  pair  of  arrows  Dbi  — Dc  and 

Dc<-<^b2\  — Db2  so  that  the  diagram  in  Figure  3-33(b)  commutes. 
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a.  Pushout  in  dK 


b.  Pushout  wiien  a  dX  object  is  viewed  as  a  functor  D:G  — >X 
and  a  dX  arrow  is  viewed  as  the  pair  of  functors  <5,  a> 


Figure  3-33,  Underlying  structure  of  a  category  <fX  pushout 

(1)  Given,  Dbi  <-<881,  Obi^  Da  — <5b2,  Ob2>->’  Db2,  as  in  Figure  3-33(b),  construct  shape  Gc,  and 
functors  Obi’,  and  aB2’  as  flie  pushout  object  and  arrows  of  the  shape  category  diagram  Gbi«-Ga->Gb2 
(Proposition  3.4).  The  back  square  of  Figure  3-33(b)  is  now  complete.  The  domain  of  functor  Dc  is  known 
to  be  shape  category  Gc-  Step  2  uses  Shape  Gc  and  diagram  Dbi<— Da— >Db2  to  determine  the  pushout 
object  Dc. 

(2)  The  objects  of  category  X  in  the  image  of  (functor)  diagram  Dc  are  constracted  by  taking  the 
colimit  of  a  “cover”  diagram,  that  consists  of  select  X-objects  and  X-arrows  from  (and  between)  category  X 
diagrams  Da,  Dbi,  and  Db2.  The  arrows  of  category  X  diagram  Dc  are  the  universal  arrows  between  a 
colimit  object  of  a  cover  diagram  and  a  cocone  object  of  a  cover  diagram. 


The  diagram  ftmctor  Dc:Gc->X  is  the  pair  of  functions  <  Dobject)  Daitow  >  defined  as  follows: 

Definition  of  Dobject^ 

For  each  a  e  Objects(Gc), 

Dobject(a)  =  Colimitx(Do),  where  the  cover  diagram  Da  is  defined  as  follows: 

Let  C-Nodes(a)  =  { dom(/)  1/  €  Arrows(Gc)  and  cod(/)  =  a} 
i.e.  tile  nodes  of  Gc  that  have  arrows  to  a. 

Let  A-Nodes(a)  =  {t)  |  e  Objects(GA),  and(aBr  »  ctbiXti)  e  C-Nodes(a)} 

Let  Bl-Nodes(a)  ={ti  |  r|  e  Objects(GBi),  and  aBi’('n)  ^  C-Nodes(a)} 

Let  B2-Nodes(a)  ={t|  j  ti  e  Objects(GB2),  and  cTB2’(n)  ^  C-Nodes(a)} 
i.e.  the  nodes  in  Ga,  Gbi,  Gb2  that  are  mapped  to  the  C-nodes. 

Let  A-Objects(a)  =  {Da(ti)  |  €  A-Nodes(a)} 

Let  Bl-Objects(a)  =  {Dbi(t|)  |  r\  e  Bl-Nodes(a)} 

Let  B2-Objects(a)  =  {Db2(ti)  I  e  B2-Nodes(a)} 

i.e.  tiie  X  objects  underlying  the  indicated  Ga,  Gbi,  and  Gb2  nodes. 

Let  A-Arrows(a)  =  {  Da(/)  \f  e  AttowsCGa)  and  dom(/),  cod  (/)  c  A-Nodes(a) 

Let  Bl-Arrows(a)  =  {  Dbi(/)  \f  e  ATrows(GBi)  and  dom(/),  cod  (/)  c  Bl-Nodes(a) 

Let  B2-Arrows(a)  =  {  Db2(/)  1/ e  Arrows(GB2)  and  dom(/),  cod  (/)  c  B2-Nodes(a) 
i.e.  the  X  arrows  imderlying  the  arcs  between  the  indicated  Ga,  Gbi,  Gb2  nodes. 

Let  8-Bl-Airows{a)  =  {Sbi(ti)  I  ^  A-Nodes(a)} 

Let  5-B2-Arrows(a)  =  {5b2(ti)  I  ti  e  A-Nodes(a)}  . 

i.e.  the  X-arrows  underl)dng  the  diagram  morphism^associated  with  the  indicated  nodes. 


Objects(Da)  =  A-Objects(a)  u  Bl-Objects(a)  u  B2-Objects(a) 

Arrows(Da)  =  A-Anows(a)  u  Bl-Arrows(a)  u  B2-Arrows(a)  u 

5-Bl-Arrows(a)  u  8-B2-Arrows(a)  u  identity  arrows 
and  closed  imder  composition 

Definition  of  Daitow^ 

For  each/ e  Arrows(Gc), 

Daitow(/)  =  the  universal  arrow  between  Dobject(tiom(/))  and  Dobject(cod(/)), 

which  are  the  colimit  object  and  a  cocone  object  respectively  of  the  cover  diagram  Ddom(/)- 

As  a  further  explanation  of  Da^w,  there  is  an  extension  morphism  Ddom(/)  Dcod(/)  between  the 

cover  diagrams  Ddoiii(/)  and  Dcod(/)  tbr  each / e  Aitows(  Gc  )•  Because  of  tins  extension  morphism  tiie 

proof  of  the  existence  of  a  universal  arrow  depicted  in  Figure  3-18  applies. 

Note  that  because  tiie  X-objects  of  diagram  Dc  are  constructed  using  the  colimit  operation  and  the 

X-arrows  of  Dc  are  universal  arrows,  diagram  Dc  must  be  a  commuting  diagram  whether  or  not  diagrams 

Da,  Dbi,  or  Db2  are  commuting  diagrams. 

In  Figure  3-33(b)  tiie  functors  Obi’,  aB2’,  and  Dc  (depicted  as  dashed  arrows)  have  been 
determined.  To  complete  the  diagram  in  Figure  3-33(b),  functors  8bi’  and  8b2’  are  constructed  in  Step  3. 
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(3)  The  functor  8bi’  is  the  pair  of  functions  <8object,  8Am>w>:GBi^X^  defined  as  follows; 

For  each  a  €  Objects(GBi), 

8object(a)  =  the  colimit  cocone  arrow  DBi(a)-»Dc(CTBi ’(«))• 

This  arrow  occurs  in  the  colimit  diagram  of  the  cover  diagram  DpGp->X,  where  (}  =  Obi’(®),  because 
Dc(oBr(tt))  “  coliinit(Dp),  and  a  6  Objects(Gp),  and  therefore  DBi(ot)  =  Dp(a). 

For  each/ e  Arrows(GBi), 

8Am.w(/)  =  <5,t> 

where  s  e  Arrows(DBi(GBi))  such  that  dom(s)  =  DBi(dom(/))  and  cod(s)  =  DBi(cod(/)), 
t  e  Arrows(aBi’  ®  Dc)(Gc)  such  that  dom(f)  =  (obi’  °  Dc)(dom(/))  and 

cod(f)  =  (  Obi’  »  Dc)(cod(/)). 

Note  that  the  functor  Obi^Gbi^Gc  and  Step  (2)  guarantees  that  a  “f  X-arrow  exists  for  each  “s” 
X-arrow.  Because  die  “t”  X-arrow  is  a  universal  arrow  and  a  cocone  arrow  of  a  diagram  involving  the  “j” 
X-arrow  die  X-arrow  pair  <s,  f>  along  with  the  X-arrows  8object(cod(/))  and  8object(dom(/))  form  a 
commuting  square.  Note  also  that  the  term  (ctbi’  °  Dc)  is  the  functor  from  shape  Gbi  to  die  restriction  of 
diagram  Do  thus  (obi’  «  Dc)(dom(/))  and  (obi’  °  DcXcod(/))  are  X-objects  in  diagram  Dc- 

Functor  8b2’:Gb2->X"*  is  similarly  constmcted  over  functors  Db2:Gb2->X,  Cb2’:Gb2^Gc>  and 
Dc:Gc->X.  The  diagram  in  Figure  3-33(b)  is  now  complete. 

The  diagram  Dbi  <-<8bi,  aBi>— Da— <8b2,  crB2>-»’  Db2  with  constmcted  object  Dc:Gc->X  and 
arrows  Dpi— <861’,  aBr>^  Dc  •<-<8b2’,CTb2’>^Db2  fonn  a  commuting  square  by  construction. 

3.6.2  Example  pushout  in  category  </X 

An  example  category  dK  diagram,  Dbi<“Da— >Db2  in  Figure  3-34,  aids  in  visualizing  how  the 
operation  defined  in  Definition  3.26  constmcts  the  rfX-object  Dc  and  </X-arrows  <  8bi  ,<rBi  ^'Dbi— >Dc, 

<  8B2’,<rB2’  >:Dbi^Dc.  The  diagram  in  Figure  3-34  is  a  specific  example  of  the  generic  stmcture  depicted 
in  Figure  3-33.  The  labels  in  diagrams  Da,  Dbi,  and  Db2  in  Figure  3-34  are  the  actual  designations  of  die 
X-objects  in  the  diagram.  The  labels  in  diagram  Dc  are  merely  placeholder  names  as  the  actual  X-objects 
are  to  be  determined  by  the  constraction. 


79 


step  (1);  In  Figure  3-34,  shape  Gc  and  shape  morphisms  Obi’,  and  032’  are  determined  by  taking 
the  pushout  of  the  category  of  shapes  diagram  Gbi<— Ga— >Gb2'  Thus,  the  domains  of  the  diagram  functors 
Dj,;Gc->X,  8bi’:Gbi-»X^,  and  5b2’:Gb2->X^  are  known  after  this  step  but  the  actual  X-arrows  and 
X-objects  in  the'codomain  of  diagram  functor  Dc  and  flie  X“*-arrows  and  X“^-objects  in  the  codomain  of 
diagram  functors  831’  and  832’  are  unknown  (hence  the  thick  dashed  arrows  representing  those  functors). 
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step  (2):  The  cover  diagrams  that  are  used  to  construct  the  X-objects  and  X-arrows  of  the 

diagram  Dc  in  Figure  3-34  are  defined  as  follows: 

Objects(  Dq )  =  {B1 1}  and  Aitows(  Dq  )  =  {  jV/bi,  )  • 

Objects(  Dq  )  =  {B2,}  and  ATrows(  Dq  )  =  { 1^82, } • 

Objects(Dq  )  =  {Bli,  BI2}  and  Arrows(Dcj )  =  {Bli->Bl2,  }• 

Objects( Dq )  =  {Aj,  B1 1,  BI3,  B2i,  B22}  and 

Arrows(Dq  )  =  {Ai->Bl3,  Ai->B2i,  Bli->Bl3,  B2,->B22,  and  identity  arrows} . 
Objects(Dq )  =  Objects(Dc^ ) {A2,  A3, BI4,  BI5,  B23}  and 

Arrows{Dq  )  =  Arrows(Dq  )  u  {  BI3— >Bl4,  BI3— >Bl5,  B22->B23,  and  id  arrows}. 
Objects(  Dq )  =  Objects(  Dq  )  u  {B24}  and 

Arrows(Dq )  =  Arrows(Dq )  u  {B22->B24,  id^j^  }■ 

The  X-objects  of  diagram  Dc  are  determined  by  taking  the  colimit  of  the  cover  diagram  of  that 
X-object.  The  (trivial)  colimit  of  diagram  Dq  is  object  B1  j.  Thus  node  Cj  in  diagram  Dc  Figure  3-34  is 

Ihe  X-object  Bl,.  The  node  labeled  C2  in  diagram  Dc  is  colimit(Dcj ),  which  is  object  B2i.  The  node 
labeled  C3  is  colimit(  Dq  ),  which  is  object  BI2.  The  node  labeled  C4  is  coliniit(  Dq  ),  which  is  equivalent 

to  the  pushout  object  of  diagram  Bl3^Ai—>B22.  Finally,  the  nodes  labeled  C5  and  Cg  are  die  colimit 
objects  of  their  respective  cover  diagrams,  Dq^  andDq  . 

The  X-arrows  of  diagram  Dc  are  the  universal  arrows  between  a  colimit  object  and  any  other 
cocone  object.  Note  that  if  there  is  an  arrow  a->P  in  Dc  (as  indicated  by  the  shape  Gc)  dien  the  cover 
diagram  Dp  is  an  extension  of  the  cover  diagram  Da.  (The  X-objects  and  X-arrows  of  the  cover  diagram  of 
node  C4  are  a  subset  of  diose  of  the  cover  diagram  of  node  C5.)  Thus  there  is  a  universal  arrow  a^P 
induced  by  the  colimit  and  cocone  arrows  of  the  cover  diagram  Da  to  a  and  P  respectively. 

Step  (3):  The  category  X^  diagrams  8bi’:Gbi-^X^  and  8b2’:Gb2-^X^  are  determined  in  the 
following  manner:  The  objects  in  Gbi  and  Gb2  are  mapped  to  the  cocone  X-arrows  formed  by  the  colimit 
of  die  category  X  cover  diagrams.  The  arrows  in  Gbi  and  Gb2  are  majjped  to  the  related  pairs  of  X-arrow  in 
diagrams  (Dbi  and  Dc)  and  (Db2  and  Dc)  that  must  necessarily  form  commuting  squares  with  the  X-arrows 
previously  assigned  to  the  objects  of  Gbi  and  Gb2- 

As  an  example,  the  X-arrow  Bl3->Cl4  is  the  cocone  arrow  to  node  C4  formed  by  the  colimit  of  the 
cover  diagram  of  node  C4  (of  which  BI3  is  an  object).  The  X-arrow  BU^Cs  is  formed  similarly.  Thus 
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X-arrows  Bl3->C4  and  Bl4->C5  are  objects  of  the  category  X"^  diagram  5bi’.  The  pair  of  X-arrows 
Bl3-^Bl4  and  C4->C5  form  a  commuting  diagram  with  X-arrows  Bl3-^C4  and  B^-^Cs  and  are  thus 
assigned  as  an  arrow  of  the  category  X"^  diagram  8bi’.  Every  object  and  arrow  of  the  category  X"^  diagram 
8bi  ’  (and  8b2’)  can  be  assigned  in  such  a  manner. 


3.6.3  Category  JX  has  pushouts  for  all  Nice  diagrams 

While  die  operation  defined  in  Section  3.6.1  is  defined  for  all  category  dK  diagrams  of  the  form 
Dbi<-Da^Db2,  it  is  not  the  pushout  operation  for  all  such  dX  diagrams.  Specifically,  the  operation 
defined  in  Section  3.6.1  is  the  pushout  operation  for  “Nice”  rfX  diagrams  that  when  flattened  (Definition 
3.18)  yields  a  commuting  category  X  diagram. 

Definition  3.27.  A  category  dX.  diagram  T)  is  termed  Nice  if  Flatten(H)  is  a  commutative  diagram. 
Proposition  3.28.  Category  dX  has  pushouts  for  all  Nice  diagrams  of  the  form  Dbi<-Da“^Db2  (assuming 
category  X  is  cocomplete). 

Proof:  The  operation  defined  Section  3.6.1  in  Definition  3.26  constructed  a  category  dX  object  Dc  and 
the  arrows  to  it  from  a  given  category  dX  diagram  Dbi<— Da“>Db2  in  such  a  maimer  that  a  commuting 
square  was  formed.  The  constructed  object  must  be  the  minimal  such  object  to  form  a  commuting  square 
in  order  for  the  operation  to  be  designated  as  the  pushout  operation  (of  Nice  diagrams)  of  category  dX, 
Specifically,  any  other  dX  object,  Dx,  that  also  forms  a  commuting  square  with  the  diagram 
Dg j  .^<5g crBi> —  Da  — <6b2,  crB2>“»  Db2j  must  have  a  unique  arrow  to  it  from  flie  constructed  object  Dc, 
namely  the  arrow  <8u,  ctu>  depicted  in  Figure  3-35. 


D. 


B2 


Figure  3-35.  Required  universal  arrow  for  object  Dc  to  be  the  pushout  object 
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Minimality  of  tfae  constructed  pushout  object  Dr:  Assume  that  a  dK  object  Dx’Gx~^X  exists  that  foims  a 
commuting  square  with  the  given  pushout  diagram.  A  unique  arrow  <5u,  0\j>:Dc-^^x  is  constructed  as 
follows: 

The  shape  morphism  Ou  of  the  arrow  <5u,  cyu>  is  die  universal  arrow  between  the  colimit  object 
Gc  and  a  cocone  object  Gx  of  die  shape  category  diagram  Gbi4-Ga”>Gb2-  (Because  shape  Gc  is  the 
pushout  of  die  shape  category  diagram  Gbi<— Ga->Gb2,  and  shape  Gx  must  have  a  cocone  of  shape 
moiphisms  to  it  from  that  same  diagram,  there  must  be  a  unique  shape  category  morphism  from  Gc  to  Gx.) 

The  shape  category  morphism,  au:Gc^Gx,  is  used  to  associate  every  X-object  and  X-arrow 
widiin  diagram  Dc  with  an  associated  X-object  and  X-arrow  within  diagram  Dx-  Each  X-object  in  diagram 
Dc  is,  by  constmction,  the  colimit  of  a  category  X  (cover)  diagram  made  up  of  X-objects  and  X-arrows  in 
(and  between)  diagrams  Da,  Dbi,  and  Db2.  The  associated  X-object  in  diagram  Dx  must  be  that  same 
colimit  object  or  it  must  be  the  target  of  some  other  cocone  morphism  from  that  same  cover  diagram  in 
order  for  Dx  to  be  part  of  a  commuting  diagram.  In  either  case  there  is  a  umque  (umversal)  X-arrow  from 
each  (colimit)  X-object  in  diagram  Dc  to  the  associated  (cocone)  X-object  in  diagram  Dx. 

For  each  a  e  Objects(Gc), 

8u.object(a)  =/  where/:Dc(a)^Dx(au(a))  is  the  universal  arrow  between  a  colimit  object, 

Dc(a),  of  the  cover  diagram  D^  and  a  cocone  object,  Dx(au(a)),  of  that  same  diagram. 

The  X-objects  and  X-arrows  in  diagrams  Dc  all  commute  with  the  X-objects  and  X-arrows  inside 
(and  between)  diagrams  Da,  Dbi,  and  Db2  by  construction.  The  X-objects  and  X-arrows  in  diagram 
Dx  ®  ^11  commute  with  diagrams  Da,  Dbi,  Db2  because  Dx  is  assumed  to  be  part  of  a  commuting 

diagram. 

For  each  /  g  Arrows(Gc), 

Su.Arrow(/)  =  <  Wl  (^X  °  (/)>• 

Thus  8u(/),/  e  Arrows(Gc)  is  the  pair  of  X-arrows,  one  from  diagram  Dc  and  one  from  diagram 
Dx,  that  [along  with  die  universal  X-arrows  5u-obiect(dom(/))  and  5u.object(cod(/))  ]  complete  a  commuting 
square  in  category  X. 

If  diagram  Dx  has  additional  structure  beyond  the  minimum  needed  based  on  the  shape  category 
Gc  then  the  same  logic  applies  as  the  extra  “structure”  of  diagram  Dx  is  ignored  by  the  restriction  Dx  °  ctu- 
If  diagram  Dx  has  “collapsed”  some  of  the  requisite  structure  based  on  shape  Gc  (shape  morphism 
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(jy;Gc-^Gx )  then  the  “collapsed”  X-  objects  within  diagram  Dx  will  still  have  cocone  arrows  to  them  from 
all  of  the  cover  HiagramR  for  which  the  Dc  specification  has  colimit  arrows  and  the  same  logic  applies.  The 
arrow  is  guaranteed  to  be  unique  as  the  individual  X-arrows  making  up  the  Dc-^Dx  arrows 
connecting  the  diagrams  are  miique.  ^ 

3.6.4  Category  dX  has  colimits  for  all  Nice  diagrams 

Any  category  that  has  an  initial  object  and  all  pushouts  is  cocomplete  [Gol84].  Because  the 
operation  defined  in  Section  3.6.1  is  the  pushout  operation  only  for  Nice  dX  diagrams  it  cannot  be  used  to 
prove  that  category  dX  is  cocomplete.  However,  the  operation  can  be  used  to  prove  that  all  category  dX 
diagrams  that  are  Nice  have  colimits. 

Proposition  3.29.  The  category  dX  has  colimits  for  all  Nice  diagrams  if  category  X  is  cocomplete. 

Proof:  The  empty  dX  diagram  is  the  initial  object  for  category  dX  and  it  is  a  Nice  diagram  in  category 
dX.  Because  die  colimit  of  a  diagram  of  a  category  (with  an  initial  object)  can  always  be  formed  by  taking 
successive  pushouts  (as  depicted  in  Figure  3-36),  all  Nice  category  dX  diagrams  have  columts  by 
successively  applying  the  operation  defined  in  Section  3.6.1. 


a.  Initial  diagram  b.  1st  pushout  c.  2nd  pushout  d.  Colimit 

Figure  3-36.  Constructing  a  colimit  using  successive  pushouts 

The  operation  defined  in  Section  3.6.1  was  specifically  tailored  to  operate  over  category  X 
diagrams  of  the  form  Dbi<-Da->Db2-  It  can  easily  be  extended  (made  more  generic)  to  operate  over  all 
category  dX  diagrams  by  developing  cover  diagrams  that  encompass  the  entire  dX  diagram. 
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3.6.5  Colimits  and  commuting  vs.  non-commuting  category  dK  diagrams 

This  section  describes  some  of  the  issues  with  developing  a  colimit  operation  over  non-Nice 
diagrams  of  category  dX.  This  section  represents  a  direction  for  future  work. 

Given  a  Nice  diagram  !D:Go— >dX  in  category  rfX,  its  colimit  object  DiG^X  is  guaranteed  to  be  a 
commuting  diagram.  This  means  that  if  there  exists  a  pair  of  arcs  between  two  nodes  in  shape  G  that  these 
arcs  will  be  assigned  the  same  underlying  category  X  arrow  by  functor  (diagram)  D.  This  assignment  of 
the  same  X-arrow  occurs  because  the  colimit  of  a  covering  diagram  is  used  to  construct  the  X-objects 
associated  with  the  nodes  and  a  universal  arrow  is  used  to  construct  the  X-arrow(s)  associated  with  the 
arc(s)  between  the  nodes.  For  Non-Nice  diagrams  the  colimit  object  D  may  not  be  a  commuting  diagram 
and  therefore  the  colimit  operation  and  the  imiversal  arrow  cannot  be  used  to  construct  the  imderlying 
X-objects  and  X-arrows  of  the  colimit  object. 

As  a  trivial  example,  the  colimit  of  the  singleton  non-commuting  diagram  on  the  left  in  Figure 
3-37,  where  f^g,  should  be  itself.  Unfortunately,  the  commuting  diagram  on  the  right  in  Figure  3-37, 
where  Object  C  is  a  “collapsed”  object  B,  is  constructed  using  the  colimit  operation  as  defined  in  this 
section.  The  reason  is  that  the  cover  diagram  of  “node”  C  is  a  non-commuting  diagram  (A  )  and 

therefore  taking  the  colimit  of  the  cover  diagram  will  eliminate  structure  that  under  certain  situations 
should  be  retained.  One  way  to  solve  this  problem  is  to  use  an  operation  other  than  the  colimit  operation  on 
the  covering  diagram. 


As  an  example  of  that  operation,  in  the  category  X  diagram  in  Figure  3-38  the  object  C  is  the 
colimit  object,  and  the  object  D  is  not  the  target  of  a  cocone  as/ V  g'  and  yet  (/''  «>  a)  =  (P  ©/), 
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(g  ’  o  a)  =  (P  o  g ),  and  there  is  a  unique  arrow  D->C.  Thus  object  D  has  retained  some  of  the  stmcture  that 
has  been  lost  in  object  C  in  that  diagram. 


Figure  3-38.  Pushout-like  structure-preserving  operation 

Object  D  can  be  constracted  as  depicted  in  Figure  3-39.  On  the  left  in  Figure  3-39,  two  pushouts, 
using  arrowy^ and  then  arrow  g,  construct  objects  Dy-and  Dg.  On  the  right  the  pushout  of  diagram 
Dy-e-  B2  Dg  constmcts  object  D.  Also  on  the  right,  composing  arrows  through  Df  and  Dg  formed  non¬ 
commuting  arrows  f  ‘and  g’.  The  arrow  to  the  colimit  object  C  is  guaranteed  to  exist  as  flie  colimit  of  the 
diagram  on  die  right  in  Figure  3-39  (including  the  object  D)  is  object  C.  It  may  be  that  this  operation,  when 
defined  over  larger  non-commuting  diagrams,  will  serve  as  the  appropriate  operation  to  apply  to  the 
covering  diagram  that  enables  the  proof  of  cocompleteness  to  be  extended  to  all  category  <£X  diagrams. 


Figure  3-39.  Construction  of  “structured  pushout” 


An  alternative  approach  to  proving  that  category  rfX  is  cocomplete  may  be  to  use  a  different 
covering  diagram  than  the  maximal  one  used  by  die  constraction  defined  in  this  section.  For  example,  in 
the  trivial  example  in  Figure  3-38  each  node  could  be  used  as  its  own  covering  diagram.  This  “minimal” 
covering  diagram  may  be  difficult  to  determine  for  more  complex  non-commuting  diagrams. 
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3. 7  Contributions  and  Future  Work 

The  main  contributions  of  this  chapter  are  flie  definition  of  a  morphism  between  diagrams  of  an 
arbitrary  category,  and  die  definition  of  a  diagram  category  dX  based  on  diagrams  of  an  arbitrary  category. 
The  category  dX  enables  diagrams  and  diagram  morphisms  to  be  treated  as  objects  and  arrows  within  a 
category  and  is  a  generali2ation  of  the  work  done  in  [SJ95].  A  diagram  morphism  is  useful  as  it  ensures 
that  both  the  stracture  and  the  content  of  one  diagram  is  preserved  in  another. 

The  proof  that  the  category  of  shapes  is  coconqilete  is  original  and  fairly  straightforward.  The 
proof  of  the  colimit  operation  over  Nice  diagrams  in  category  dX  is  original  as  well  and  of  greater 
significance.  Even  though  the  full  category  rfX  has  not  been  proved  to  be  cocomplete,  colimits  over  die 
Nice  dX  diagrams  are  sufficient  for  their  use  in  this  dissertation  in  later  chapters. 

The  secondary  contributions  of  this  chapter  are  die  operations  and  functors  defined  over  the 
categories  X,  dX  and  the  diagrams  of  those  categories.  The  functors  are  Diagramize  and  Colimit.  The 
operations  are  Flatten,  Partition,  Join,  and  Fold.  Also  of  note  is  the  definition  of  an  extension  morphism  in 
the  category  dX  along  widi  the  notions  of  parameterization  and  instantiation. 

The  notion  of  parameterized  diagrams  developed  in  this  chapter  is  very  weak  but  can  be  extended 
when  applied  to  diagrams  of  a  particular  category  such  as  category  Spec  in  Chapter  4.  The  operations 
together  with  the  notion  of  parameterization  and  instantiation  are  used  in  Chapter  5  to  formally  define  the 
semantics  of  a  syntax  for  constracting  and  manipulating  diagrams  on  a  higher  level. 

Future  work  involves  extending  the  pushout  and  colirmt  operations  (and  proofs)  for  diagram 
categories  to  extend  over  all  the  diagrams  of  category  dX  instead  of  just  those  over  Nice  diagrams. 
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4  The  Category  of  Specification  Diagrams 

This  chapter  applies  the  diagram  theory  developed  in  Chapter  3  to  the  category  Spec  presented  in 
Appendix  A  in  order  to  derive  the  category  dSpec.  This  category  has  diagrams  of  specifications  and 
morphisms  as  the  objects  and  diagram  morphisms  as  the  arrows.  All  of  the  operations  and  fimctors 
developed  for  category  dX  are  applicable  to  category  dSpec.  lliis  chapter  also  defines  several  properties 
and  operations  of  the  objects,  arrows  and  diagrams  of  category  dSpec  that  are  used  in  later  chapters.  Thus 
this  chapter  develops  the  theory  underlying  category  dSpec  that  is  not  generic  to  all  diagram  categories. 

Many  of  the  properties  defined  oyer  the  category  dSpec  arrows  in  diis  chapter  are  based  on  similar 
properties  defined  over  category  Spec  arrows.  This  chapter  also  applies  the  theory  underl3dng 
parameterized  diagrams,  Section  3.5.4,  to  diagrams  in  category  Spec  and  then  fiuiher  extends  that  theory 
based  on  the  properties  of  category  Spec  and  dSpec.  Finally,  this  chapter  develops  the  notion  of  a  diagram 
interpretation  that  forms  the  basis  for  representing  design  information  in  Chapter  6. 

Section  4.1  defines  category  dSpec,  defines  what  it  me^ns  for  a  dSpec  arrow  to  be  a  conservative 
or  definitional  extension  morphism  and  defines  the  model  semantics  for  these  objects  and  arrows.  Section 
4.2  defines  what  it  means  to  be  a  parameterized  diagram  in  dSpec.  Section  4.3  defines  diagram 
interpretations,  morphisms  between  diagram  interpretations  and  the  category  dinterp.  This  section  also 
defines  die  model  semantics  of  diagram  interpretations  and  conqiares  them  to  interpretations  and  diagram 
refinement. 

4. 1  The  Category  of  Spec  Diagrams,  dSpec 

The  category  dSpec  is  the  diagram  category  (Proposition  3.13)  derived  firom  category  Spec.  Its 
objects  are  Hijigrams  of  category  Spec  (Proposition  B.19)  and  its  arrows  are  diagram  morphisms  (Definition 
3.12)  between  die  Spec  diagrams. 

The  following  functors  and  operations  are  defined  over  category  dSpec  and  category  Spec  and  the 
diagrams  of  those  categories 

Diagramize:  Spec-^dSpec  (Proposition  3.15). 

Colimit:  dSpec->Spec  (Proposition  3.17). 
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Flatten;  dSipec-diagram  ->  Spec-diagram  (Definition  3.18). 

Partition:  Spec-diagram  x  Partition-morphism  -4  rfi^ec-diagram  (Definition  3.20). 

Nice  diagrams  (Definition  3.27)  of  category  dSpec  have  colimits  (Proposition  3.29). 

As  category  dSpec  objects  and  arrows  are  related  to  category  Spec  objects  and  arrows  via  the 
Colimit:  dSpec-^Spec  functor,  fire  model  semantics  (Section  B.2)  of  category  dSpec  objects  and  arrows  can 
be  defined  in  terms  of  the  model  semantics  of  die  associated  category  Spec  objects  and  arrows.  Thus  dSpec 
objects  have  the  same  model  semantics  as  their  associated  Spec  objects  as  defined  in  Section  B.2.5  and 
dSpec  arrows  have  the  same  model  semantics  as  their  associated  Spec  arrows  as  defined  in  Section  B.2.6. 
Each  dSpec  object  has  an  associated  class  of  models  and  each  dSpec  arrow  has  an  associated  reduct  functor 
that  takes  target  models  to  source  models  by  forgetting  the  lumeeded  earner  sets  and  functions. 

4.1.1  Conservative  and  definitional  extension  arrows  in  dSpec 

Given  a  category  dSpec  diagram  V:G^dSpec,  the  functor  Colimit:  dSpec-^Spec  yields  a  category 
Spec  diagram  with  the  same  shape  G,  i.e.  Colimit  °  ‘D:G-^dSpec  =  D:G->^Spec.  As  every  dSpec-zrtow  has 
an  associated  Spec-arrow  via  the  Colimit  functor,  dSpec  arrows  can  be  classified  as  conservative  extensions 
or  definitional  extensions  based  on  the  classification  of  the  colimit  of  the  arrow  in  category  Spec. 
Definition  4.1.  A  morphism,  D,->D2,  in  dSpec  is  a  conservative  extension  morphism  or  a  definitional 
extension  morphism  in  dSpec  if  the  Spec  arrow  CofiwiXDi-^Dz)  is  a  conservative  extension  morphism  or  a 
definitional  extension  morphism  in  Spec  respectively. 

Notation:  The  labeled  arrows  — c— >  and  — d— >  in  dSpec  diagrams  indicate  the  property  of  being  a 
conservative  or  definitional  extension  morphism,  the  same  as  they  do  for  Spec  (Definition  C.8  and 
Definition  C.12). 

Proposition  4.2.  Conservative  and  definitional  extension  morphisms  are  closed  under  composition  in 
dSpec. 

Proof:  If  A-x->B  and  B-x-^C  are  conservative  extensions  or  definitional  extensions  in  dSpec  then 
Colimit  (A-x^B)  and  Colimit  (B-x->^C)  are  conservative  extensions  or  definitional  extensions  in  Spec  by 
definition.  Since  those  properties  are  closed  under  the  composition  operation  in  Spec  (Proposition  C.15) 
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and  Colimit  (A-x->B)  »  Colimit  (B-x->C)  is  equal  to  Colimit  (A-x^B  o  B-x-»C)  these  properties  are 

closed  under  composition  in  dSpec.  ^ 

Pushouts  in  category  Spec  were  proven  to  have  preserved  conservative  and  definitional  extension 

moiphisms  (Proposition  C.19).  The  same  is  trae  for  category  dSpec  morphisms. 

Proposition  43.  Pushouts  in  dSpec  preserve  conservative  and  definitional  extension  morphisms.  (Those 
properties  reflect  across  a  pushout  square.) 

Proof:  Functor  Colimit  takes  a  dSpec  pushout  diagram  to  a  Spec  pushout  diagram.  Functor  Colimit  takes 
the  dSpec  pushout  object  to  the  associated  Spec  pushout  object.  Therefore,  since  conservative  extensions 
and  definitional  extensions  are  preserved  in  pushouts  in  Spec,  they  must  also  be  preserved  in  pushouts  in 

dSpec 

Category  Spec  morphisms  that  are  conservative  extensions  and  definitional  extensions  were 
defined  so  as  to  establish  reduct  functors  that  had  properties  that  were  useful  for  describing  the  refinement 
of  specifications  and  describing  parameterization.  These  same  properties  hold  for  category  dSpec  objects 
and  arrows  and  the  refinement  and  parameterization  of  diagrams  of  specifications.  Thus  for  conservative 
extension  morphisms  in  dSpec,  each  model  associated  with  the  source  diagram  can  be  extended,  sometimes 
in  many  different  ways,  so  as  to  be  a  model  of  the  target  diagram.  (As  described  in  Section  C.1.4  for  Spec 
conservative  extension  morphisms.)  Also,  for  definitional  extension  morphisms  in  dSpec,  each  model 
associated  with  the  source  diagram  can  be  extended  in  a  unique  way  so  as  to  be  a  model  of  the  target 
diagram.  (As  described  in  Section  C.1.5  for  Spec  definitional  extension  morphisms.) 

4.1.2  dSpec  diagrams 

Category  dSpec  diagrams  are  diagrams  of  category  X  diagrams;  these  multiple  levels  can  be 
confusing  so  this  section  introduces  a  notation  to  keep  the  confusion  to  a  minimum. 

An  example  diagram  in  dSpec  that  contains  a  definitional  extension  morphism  is  depicted  in 
Figure  4-1.  The  figure  depicts  two  levels  of  diagrams:  Spec  diagrams  and  dSpec  diagrams.  Identity  arrows 
were  left  off  of  the  two  diagrams  to  make  them  less  complicated.  On  the  right  in  Figure  4-1  two  simple 
Spec  diagrams  Bag  (One-Sort-^Bag)  and  SetAsBag  (One-Sort  ^  SetAsBag)  are  joined  together  by  a 
diagram  morphism  fliat  connects  die  “parameters”  (specification  One-Sort)  and  the  “bodies”  (specification 
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Bag  and  Specification  SetAsBag)  of  the  diagram.  On  the  left  in  that  figure  the  two  Spec  diagrams  (Bag  and 
SetAsBag)  are  viewed  as  dSpec  objects  and  the  diagram  morphism  between  them  becomes  a  dSpec  arrow. 
The  dSpec  arrow  is  a  definitional  extension  morphism  as  Co/imi7(Bag->SetAsBag)  is  a  definitional 
extension  morphism  in  Spec, 


Figure  4-1,  Example  dSpec  diagram  and  underlying  Spec  diagrams  and  diagram  morphisms 


SetAsBag 


Figure  4-2.  Single  diagram  representing  ail  of  the  detail  depicted  in  Figure  4-1 


In  the  remainder  of  the  document,  in  figures  of  dX.  diagrams,  the  relationship  between  the  shape 
category  and  the  target  category  and  the  relationship  between  dSpec  diagrams  and  Spec  diagrams  will  be 
subsumed  using  a  single  picture.  For  example,  the  dSpec  diagram  and  underlying  Spec  diagrams  in  Figure 
4-1  will  be  depicted  as  in  Figure  4-2  where  the  dashed  ovals  represent  dSpec  objects  and  arrows  and  the 
contents  of  the  ovals  represent  the  underlying  Spec  diagrams  and  diagram  morphisms.  (Note  that  in  Figure 
4-1  and  Figure  4-2  the  terms  “Bag”  and  “SetAsBag”  are  being  used  to  name  both  a  diagram  and  a 
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specification  within  that  diagram.)  The  shapes  of  the  Spec  and  dSpec  diagrams  can  be  inferred  from  what 
is  depicted  in  Figure  4-2  as  long  as  only  Nice  diagrams  are  depicted. 


4.1.3  Constracting  conservative  and  definitional  extension  morphisms  in  rfSpec 

Just  as  building  upon  previously  existing  specifications  can  extend  objects  in  Spec  (Section  C.1.2), 
building  upon  previously  existing  objects  in  dSpec  can  extend  objects  in  dSpec.  A  simple  way  to  extend  a 
dSpec  object,  D|,  so  that  its  extension,  Da,  has  one  of  the  named  anow  properties  in  Definition  4.1  is 
depicted  in  Figure  4-3.  In  Figure  4-3  die  Spec  object  C,  which  is  colimitspa  (Di),  is  extended 
conservatively  or  definitionally  to  create  a  Spec  object  F.  The  resultant  Spec  object  is  then  treated  as  a 
dSpec  object,  i.e.  Da  =  Diagramizei^).  The  dSpec  arrow  Di->Da  is  simply  the  colimit  cocone  arrows 
individually  composed  widi  the  extension  arrow,  C-^F.  As  the  Spec  arrow  C->F  was  constracted  to  be  one 
of  the  indicated  extension  morphisms,  the  dSpec  arrow  D|-»Da  is  also  classified  as  such  an  arrow. 


Figure  4-3.  Creating  (conservative,  definitional)  extensions  in  dSpec 


The  construction  depicted  in  Figure  4-3  is  guaranteed  to  result  in  a  diagram  morphism  between 
diagrams  as  the  colimit  induced  cocone  morphisms  to  specification  C  commute,  and  therefore  the  related 
cocone  morphisms  to  specification  F  commute  as  well. 
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4. 1 .4  Specifying  diagram  morphisms 

In  order  to  develop  a  diagram  morphism,  <  5,  o  >:D,->D2,  one  must  establish  which  Spec  arrows 
connect  the  specification  objects  of  the  source  diagram  to  the  specification  objects  of  the  target  diagram. 
Under  certain  conditions  associating  the  specification  morphisms  between  the  “nodes”  of  the  diagrams  is 
enough  to  induce  a  diagram  morphism  between  the  diagrams.  The  syntax  presented  in  Figure  4-4 
establishes  a  morphism  between  diagrams  by  establishing  individual  morphisms  between  the  objects 
(nodes)  in  the  two  diagrams. 

Diaaram-Momhi sm  dMorphism  [  dMorvhi sm -Name  :  ] 

diaa-ref  ->  diacr-ref  is 

(  import -morphism  |  Arc  (  ,  Arc  )  *  ) 

arc  — >  [  arc-name  :  ]  a-node-ref  ->  a-node-ref  :  siq-mappinq-term 

sia-maDPina- term  — >  {  [  sicr-map-rule  ( ,  siq-map-rule  )  *  ]  } 

sia-mappina- term  —>  morphism-ref 

sicr-map-rule  — >  (  op -ref  ->  op-ref  )  \  (  sort- ref  ->  sort- ref  ) 

Figure  4-4.  Syntax  for  a  diagram  morphism 

Assume  that  the  source  diae-refis  the  diagram  DiiGi— >5pec,  and  the  target  diag-ref  is 
D2:G2-^Spec.  If  diagram  D2  was  constructed  by  inqjorting  D,  (the  diagram  statement  Section  5.2.2  Figure 
5-3),  flien  the  term  “import -morphism”  indicates  the  associated  diagram  morphism.  Otherwise,  each 
individual  specification  object  in  Di  must  have  a  single  specification  morphism  (arc)  to  a  specification 
object  in  D2  as  indicated  by  a  collection  of  Arc  clauses  in  the  diagram  morphism  statement  The  collection 
of  specification  morphisms  between  the  specification  objects  must  induce  a  shape  morphism,  o;G,-»G2,  or 
the  purported  diagram  morphism  statement  has  no  meaning  (i.e.  an  error).  If  D|  and  D2  are  Nice  diagrams 
(Definition  3.27),  then  the  shape  morphism  a:Gi->G2  can  always  be  induced.  The  collection  of 
specification  morphisms  must  also  induce  a  8  diagram,  d:Gi->Spec~*,  whose  objects  are  the  collection  of 
specification  morphisms  and  whose  arrows  are  pairs  of  specification  morphisms  (one  firom  Di  and  one  from 
D2)  as  indicated  by  the  restriction  D2  »  o  or  the  purported  diagram  morphism  statement  has  no  meaning 
(i.e.  an  error).  Both  of  these  conditions  are  easy  to  check  syntactically.  Thus,  to  be  a  correct  diagram 
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morphism  statement,  the  given  arcs/specification  morphisms  in  the  dMorphism  statement  must  induce  a 
diagram  morphism,  <8,  a>:D  i^D2. 

Figure  4-5  is  an  example  diagram  morphism  between  the  Bag  diagram,  One-Sort  ->  Bag,  and  the 


Set  as  Bag  diagram,  One-Sort-^SetAsBag. 


diagram  Set -as -Bag  is 

nodes  Set -as -Bag,  One -Sort 
arcs 

One-Sort  ->  Set-as-Bag:  {x->e} 
end -diagram 

dMorphism  Bag-to-SetAsBag: 

Bag  ->  Set-as-Bag  is 
One-sort  ->  One-Sort:  {}, 

Bag  ->  Set-as-Bag:  {} _ 


/One “Sort  \ 


{x->e} 


\SetAsBag/ 


SetAsBag 


d — Bag 


Figure  4-5.  Bag  to  SetAsBag  diagram  morphism 


Figure  4-6  is  an  example  diagram  morphism  between  the  Set  diagram,  One-Sort-»Set,  and  the 


Set  as  Bag  diagram,  One-Sort->SetAsBag. 


dMorphism  Set-to-SetAsBag : 

Set  ->  Set-as-Bag  is 
One-sort  ->  One-Sort:  {}, 

Set  ->  Set-as-Bag:  {} 


'One -Sort' 


/One -Sort  \ 


{x->E} 


Set 


x->e} 


sSetAsBag/ 


Set - ►  SetAsBag 


Figure  4-6.  Set  to  SetAsBag  diagram  morphism 


4.2  Parameterized  Diagrams  in  dSpec 

A  parameterized  object  is  an  object  with  a  variable  part  and  z  fixed  part.  When  dealing  widi 
parameterized  diagrams,  a  body  is  a  sub-diagram  of  a  dSpec  diagram  that  has  a  fixed  part  and  a  variable 
part  and  z  formal  parameter  is  a  diagram  that  represents  and  covers  the  variable  part  of  a  given  body. 

There  must  exist  a  diagram  morphism  from  the  formal  parameter  part  to  the  body  indicating  how  the  formal 
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psTEtneter  covers  the  variable  part  of  the  body.  These  informal  descriptions  of  variable  part,  formal 
parameter  and  body  and  their  relationships  with  each  other  are  defined  in  this  section. 

4.2.1  Definition  of  variable  part,  formal  parameter  and  body 

Deflnition  4.4.  Any  Spec  diagram  D,  where  tire  specification  Coliimtspec(D)  has  more  than  one  (non¬ 
isomorphic)  model,  is  said  to  have  a  variable  part. 

Definition  4.5.  Any  Spec  diagram  D,  where  the  specification  Colimitjpa;(D)  has  only  one  model  (class  of 
isomorphic  models),  is  said  to  have  no  variable  pari. 

Definition  4.4  and  Definition  4.5  use  the  number  of  non-isomorphic  models  associated  with  a 
specification  in  order  to  determine  if  a  Spec  diagram  has  “variable”  parts  or  not.  In  general,  it  is  difficult  to 
mechanically  establish  the  number  of  models  associated  with  a  specification  unless  certain  conditions  are 
met.  For  exanple  if  all  axioms  of  a  specification  are  equational  or  conditional  equational  and  initial 
semantics  is  used  then  one  can  mechanically  prove  whether  or  not  there  exists  a  single  model  associated 
with  the  specification.  The  notion  of  variable  parts  is  used  so  fliat  one  can  reason  whether  a  formal 
parameter  covers  all  of  the  variable  parts  of  a  body.  This  in  turn  is  used  so  that  one  can  reason  whether  a 
refinement  of  a  body  has  (unknowingly)  constrained  the  formal  parameters,  or  has  (unknowingly) 
introduced  additional  variable  parts. 

Deflnition  4.6.  Given  a  category  dSpec  diagram  Di,  a  category  dSpec  diagram  D2,  and  a  morphism 

the  diagram  Di  is  said  to  be  z.  formal  parameter  of  the  body  diagram  D2  and  to  fully  cover  the 
variable  part  of  D2  if  the  following  three  conditions  are  met: 

1 .  Di->D2  is  a  conservative  extension  morphism. 

2.  For  each  a  e  Objects(Di),  the  colimit  induced  cocone  arrow/:  a  ->  Colimit(Di)  is  a 
conservative  extension  morphism. 

3.  Given  that  Dx  is  a  diagram  with  no  variable  parts,  Colimit5pec(Flatten(D2^Di-->Dx))  also  has 
no  variable  parts. 

Conservative  extension  morphisms  (Figure  4-7  depicts  conditions  1  and  2)  ensure  that  the  formal 
parameter  part  actually  represents  some  part  of  the  body  specification  in  its  entirety,  so  to  speak.  Condition 
1  ensures  that  diagram  D2  does  not  restrict  the  models  associated  with  diagram  Di  when  diagram  Di  is 
taken  as  a  whole.  Condition  2  ensures  that  diagram  D2  does  not  restrict  the  models  associated  with  the 
individual  specifications  making  up  diagram  Dj.  This  ensures  that  any  actual  parameter  that  has  a 
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morphism  to  it  from  flie  formal  parameter  will  be  corrqratible  witii  the  body  and  not  have  its  properties  be 
fundamentally  changed  in  some  manner  in  the  instantiating  diagram.  Like  the  notion  of  variable  parts,  the 
notion  of  a  conservative  extension  is  also  diffrcult  to  prove  mechanically  (as  alluded  to  in  Section  C.1.4). 


However,  there  exists  a  collection  of  “conservative  extension  schemes”  [GM93]  fliat  make  the  development 
of  a  conservative  extension  (and  the  related  proof  of  existence)  easier. 


Formal  parameter 


Body 


Figure  4-7.  Parameterization  requires  conservative  extension  morphisms  (Spec  and  dSpec) 


The  notion  of  a  variable  part  existing  in  the  body  but  not  existing  in  an  instantiating  diagram 
(condition  3)  ensures  that  the  variable  part  of  diagram  D2  is  fully  covered  by  diagram  Di.  This  ensures  that 
instantiation  that  involves  an  actual  parameter  that  has  no  variable  parts  will  result  in  a  diagram  with  no 
variable  parts. 


4.2.2  Examples  of  variable  parts,  formal  parameters  and  bodies 

In  the  next  several  paragraphs,  the  terms  One-Sort,  Flag,  Set,  Map  (in  Figure  4-8),  Total-Order  and 
Tree  (in  Appendix  F)  are  all  treated  as  specifications  as  well  as  singleton  diagrams,  and  the  arrows  between 
diem  are  all  treated  as  morphisms  and  diagram  morphisms.  This  abuse  of  terminology  helps  to  avoid 
having  to  explicitly  use  die  Diagramize  (and  Colimii)  functor  over  those  Spec  (and  dSpec)  objects  and 
arrows  when  switching  between  the  different  meanings  of  the  terms. 

The  specification  One-Sort  has  many  models  associated  with  it,  as  there  are  no  axioms  that  liimt 
the  associated  models.  In  contrast,  the  specification  Flag  has  only  one  model  (or  class  of  isomorphic 
models)  associated  with  it.  In  every  model  of  specification  Flag  the  carrier  set  associated  with  the  sort  Flag 
contains  exactly  three  elements  (hence  they  are  all  isomorphic  to  each  other)  and  therefore  the  diagram 
Flag  has  no  variable  parts.  The  specification  Set  has  many  models  associated  with  it  as  the  element  sort  E 
has  not  been  “defined”,  i.e.  the  sort  E  could  be  empty,  or  could  have  any  number  of  “values”  associated 
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with  it  that  effects  how  many  elements  the  carrier  set  of  sort  Set  has  associated  with  it.  Therefore  the 
diagram  Set  has  a  variable  part.  The  specification  Tree  has  a  sort  E  and  an  order  TO  that  is  not  defined  and 
therefore  the  diagram  Tree  has  a  variable  part. 


Spec  Empty 

Spec  Empty  contains  the  sorts  Nat  and  Boolean 
--  including  operations  such  as: 

--  <  and  >  (less  than  and  greater  than) 
of  rank  Nat,  Nat  ->  Boolean 

end- spec _ _ _ _ _ _ _ 

Spec  One-Sort  is 
Sort  X 

end- spec _ _ _ _ _ _  - 

Spec  Flag  is 
sort  Flag 

op  Green:  ->  Flag 
op  Yellow:  ->  Flag 
op  Red:  ->  Flag 

constructors  {Green,  Yellow,  Red}  construct  Flag 
ax  Green  Yellow 
ax  Yellow  ^  Red 
ax  Red  Green 

end -spec _ _ _ _ _ — _ - 

spec  Set  is 
sort  Set,  E 

op  Empty:  ->  Set 

op  Insert:  E,  Set  ->  Set 
op  In:  E,  Set  ->  Boolean 

Constructors  {Empty,  Insert}  construct  Set 
Forall  s:Set,  e,el,e2:E 
Ax  not (In (e, Empty) ) 

Ax  in(el,  Insert  (e2,  s) )  ==>  ((el=e2)  v  In(el,s)) 

Ax  Insert (e,s)  =  Insert (e, Insert (e, s) ) 

Ax  Insert (el, Insert (e2,s) )  =  Insert (e2 , Insert (el, s) ) 

end- spec _ _ _ _ _ _ 

spec  Map  is 

sort  Map,  Dorn,  Cod 
op  Constant-Map:  Cod  ->  Map 

op  Modify:  Map,  Dom,  Cod  ->  Map 
op  Apply:  Map,  Dom  ->  Cod 

Constructors  {Constant -Map,  Modify)  construct  Map 
Forall  m,ml,m2:Map,  d,dl,d2:Dom,  c,  cl,  c2:Cod 
Ax  Apply (Constant-Map (c) ,d)  =  c 

Ax  Apply (Modify (m, dl, c) ,d2)  =  if  dl=d2  then  c  else  Apply(m,d2) 
Ax  Modify  (Modify  (iti,  d,  cl)  ,  d,  c2 )  =  Modify  (ni,d,  c2) 

Ax  not(dl=d2)  Modify (Modify (m,dl, cl) ,d2,c2)  = 

Modify (Modify (m,d2,c2) ,dl,cl) 

Ax  ml=m2  O  Apply  (ml,  d)  =  Apply  (m2,  d) 
end- spec _ _ _ _ 

Figure  4-8.  Code  for  Empty,  One-Sort,  Flag,  Set  and  Map  specifications 
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The  specification  morphism  Empty  ->Set  is  a  conservative  extension  morphism,  however 
specification  Empty  does  not  cover  the  variable  parts  of  specification  Set  and  therefore  diagram  En5)ty  is 
not  the  formal  parameter  of  diagram  Set.  In  contrast,  the  diagram  One-Sort  is  a  formal  parameter  of  tire 
body  diagram  Set  as  flie  morphism  {X^E}  :One-Sort  ^  Set  is  a  conservative  extension  morphism  and  die 
diagram  Set^-One-Sort-^Dx  will  have  no  variable  parts  when  diagram  Dx  has  no  variable  parts.  Diagram 
One-Sort  is  not  die  formal  parameter  of  diagram  Tree  as  diagram  Tree<-One-Sort-^Dx  still  has  variable 
parts,  i.e.  the  TO  operator  in  specification  Tree  could  have  many  different  models  associated  with  it  as  it 
has  not  been  defined.  Diagram  Total-Order  is  the  formal  parameter  of  diagram  Tree  as  the  diagram 
Tree  <-Total-Order->Dx  has  no  variable  parts. 

In  the  preceding  examples  of  parameterized  diagrams  the  body  and  formal  parameter  diagrams 
were  single  specifications.  The  example  parameterized  diagrams  in  Figure  4-9  are  more  complex  in  that 
they  take  advantage  of  having  either  die  formal  parameter  diagram  or  the  body  diagram  (or  both)  contain 


more  than  singleton  specifications. 


Map  SetList  MapOfSet 


Figure  4-9.  Example  parameterized  diagrams 

Notation:  Circles  in  Figure  4-9  represent  specifications  that  traditionally  represent  the  formal  parameters 

of  parameterized  specifications.  Squares  represent  specifications  that  traditionally  represent  the  bodies  of 
parameterized  specifications. 
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4.2.3  Parameterized  dSpec  diagrams  vs.  parameterized  diagram  theory  in  dX 


The  generic  parameterized  diagram  theory  was  introduced  in  Section  3.5.4,.  The  dieory  as 
presented  in  that  section  in  Table  3-1  is  a  good  deal  richer  than  is  needed  for  parameterized  Spec  diagrams 
presented  in  this  chapter.  Only  lower  bound  parameterization  is  used  here.  Because  of  this,  Figure  3-3 1 
(repeated  here  in  slightly  different  notation  in  Figure  4-10)  depicts  the  underlying  shape  of  every  category 


dSpec  parameterized  diagram.  The  morphism  between  the  formal  parameter  and  body  diagrams  must  be  a 
conservative  extension.  An  instantiation  moiphism  is  between  the  formal  parameter  diagram  and  some 
other  diagram  that  represents  the  actual  parameters.  Given  the  shape  of  the  formal  parameter  diagram,  the 
shape  of  the  actual  parameter  diagram  can  be  induced  directly.  (All  specifications  and  morphisms  in  the 
formal  parameter  diagram  must  be  present  in  the  instantiating  diagram.  Therefore,  ignoring  any  possible 
“collapsing”  of  shape  for  now,  the  actual  parameter  diagram  must  have  the  same  shape  as  the  formal 
parameter  diagram.) 


Formal  parameter 
diagram  i 


Actual  parameter 
diagram 


Body  X 
diagram  ■ 

Figure  4-10.  Underlying  shape  of  a  parameterized  diagram  in  category  dSpec 


Figure  4-11.  Parameterizations  in  Spec  have  the  shape  of  Figure  4-10  in  dSpec 


Given  an  actual  parameter  diagram  with  die  same  shape  as  the  formal  parameter  diagram,  the 
shapes  of  the  parameterized  diagrams  of  Figure  4-9  can  be  depicted  as  in  Figure  4-11.  The  dashed  boxes 
could  have  been  left  off  as  the  dSpec  diagram  shape  (Figure  4-10)  can  be  directly  inferred.  The  notation 
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depicted  in  Figure  4-11  (without  the  additional  dashed  boxes)  is  used  throughout  Chapter  5  (and  in 
Appendix  E)  as  tiie  formal  parameter  and  body  parts  can  be  determined  from  the  dashed  circles  and  arrows. 

4.3  Diagram  Interpretations 

A  diagram  interpretation  is  a  special  diagram  in  dSpec  fliat  consists  of  two  diagram  morphisms 
with  a  common  codomain,  where  one  of  the  diagram  morphisms  is  a  definitional  extension.  Diagram 
interpretations  are  similar  to  the  specification  interpretations  presented  in  Section  C.3  except  a  diagram 
interpretation  is  defined  over  the  category  dSpec  instead  of  die  category  Spec.  In  category  dSpec,  the  pair 
of  diagram  morphisms  S-»M^d-T  indicates  an  interpretation  of  diagrams  from  source  diagram  S  to  target 
diagram  T  via  the  mediator  diagram  M. 

4.3.1  dinterpretations,  dinterpretation  morphisms  and  the  category  dinterp 

Definition  4.7.  An  interpretation  in  dSpec,  i  =  <f,g>  consists  of  a  diagram  morphism/ and  a  diagram 
definitional  extension  morphism  g  with  a  common  codomain  diagram,  Cod(/)  =  Cod(  g  ).  A  dSpec 
interpretation,  i  =  A->B‘^<-d-B,  has  operations  dom,  med,  and  cod  defined  as  follows:  dom(i)  =  A, 
med(0  =  B"^,  and  cod(i)=  B.  These  three  diagrams  are  also  known  as  the  source,  mediator  and  target 
diagrams  of  the  dSpec  interpretation. 

We  can  visualize  the  components  of  a  dSpec  interpretation  (also  called  a  diagram  interpretation  or 
a  dinterpretation)  in  Figure  4-12  where  the  dinterpretation  S->M'«-d-T  has  been  expanded  to 
S — <8s,  Os>-»M<-<8t,  aT>— T  where /=  <8s,  CTs>  and  g  =  <5t,  aT>. 
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A  diagram  iaterpretation  means  that  the  source  diagram  can  be  implemented  by  or  refined  into  a 
definitional  extension  of  the  target  diagram.  Thus  in  order  to  refine  the  source  diagram  further  one  can 
simply  refine  the  target  diagram. 

Definition  4.8.  dSpec  interpretations  with  common  codomain/domains  compose  by  taking  a  pushout  and 
composing  the  diagram  morphisms  as  depicted  in  Figure  4-13.  This  is  similar  to  how  interpretations  in 
Spec  compose  in  Definition  C.23. 


a  A=>B=>C  lx  Pushout  c.  A=>C  Interpretation 

TVwInteiprefatioiis  CbnstnictionofC^Med  1^  Morphism  Cimi^ 


Figure  4-13.  Composition  of  interpretations  in  dSpec 


The  two  diagram  morphisms  constructed  in  Figure  4-5  and  Figure  4-6,  when  joined,  constitute  a 
dlnterpretation,  Set-^SetAsBag<-d-  Bag,  as  depicted  in  Figure  4-14.  The  code  for  the  example 


interpretation  is  depicted  in  Figure  4-15. 


Set - ►  SetAsBag  ◄ —  d — Bag 

Figure  4-14.  Set  as  Bag  diagram  interpretation 
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dinterpretation  Set-as-Bag:  Set  =>  Bag  is 
mediator  Set-as-Bag 
dom-to-med  One-Sort  ->  One-Sort: {}, 

Set  ->  Set-as-Bag:  {} 
cod-to-med  One-Sort  ->  One-Sort: {}, 

Bag  ->  Set-as-Bag:  import -morphism 


Or  given  the  code  in  Figure  4-5  and  Figure  4-6 


dinterpretation  Set-as-Bag:  Set  =>  Bag  is 
mediator  Set-as-Bag 
dom-to-med  Set-to-SetAsBag 
cod-to-med  Bag-to-SetAsBag 


Figure  4-15.  Set  as  Bag  diagram  interpretation  code 


Definition  4.9.  An  interpretation  morphism  in  dSpec  is  a  5  tuple,  im  =  <A  =>  B,  C  D,/ :A->C, 

A:B->D>,  where  dom(j>n)  =  A=>B,  cod(r/n)  =  C=>D,  dom-morphism(iOT)  =f, 
cod-morphism(j/n)  =  h,  med-morphism(im)  =  g,  consisting  of  the  domain  and  codomain  interpretations  and 
three  morphisms  between  die  domain,  codomain  and  mediator  diagrams  of  the  domain  interpretation  to  die 
domain,  codomain  and  mediator  diagrams  of  the  codomain  interpretations,  such  that  the  diagram  in  Figure 

A - — ►  B+  ■< - d - B 

V  i  " 

C - *■  D+  ■« - d - D 

Figure  4-16.  Interpretation  morphism  in  d5pec 

Proposition  4.10.  Diagram  interpretations  and  diagram  interpretation  morphisms  form  a  category,  dinterp. 
Proof:  The  identity  arrow  of  a  diagram  interpretation  is  the  identity  arrows  of  die  Source,  Mediator  and 
Target  diagrams  of  the  diagram  interpretation,  i.e.  the  identity  arrow  for  die  interpretation  A-»B"^<-d-B  is 
the  5  tuple  <  A->B  Vd-B,  A->BVd-B,  /:A-id-^A,  g:B^-id-»B^  A:B-id-^B>.  The  diagram  morphisms 
{f,  g,  h)  maVing  up  a  diagram  interpretation  morphism  individually  compose  and  individually  are 
associative,  therefore  diagram  interpretation  morphisms  compose  and  are  associative. 


4-16  commutes. 


Domain  Interpretation 


Interpretation  Morphism 

Codomain  Interpretation 
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Notation:  Note  the  notation  has  varied  on  flie  use  of  the  symbol  “J”  to  preface  a  category.  While 
category  dSpec  is  the  category  of  Spec  diagrams  and  diagram  motphisms,  category  dinterp  as  defined  in 
Proposition  4.10  is  not  the  category  of  Interp  diagrams  and  diagram  morphisms.  Instead,  category  dinterp 
is  related  to  category  dSpec  in  the  same  fashion  that  category  Interp  is  related  to  category  Spec  (Definition 
C.20).  Since  Interp  is  a  category,  there  is  a  category  ""dinterp"'  based  on  diagrams  of  interpretations,  but 
that  category  is  quite  different  from  the  dinterp  category  defined  in  Proposition  4.10. 

Proposition  4,11.  Category  dinterp  has  functors  Dorn,  Cod,  andM>rf  that  return  dSpec  objects  and  arrows. 
These  functors  return  the  domain,  codomain  and  mediator  objects  and  arrows  of  dinterp  objects  and  arrows 
as  defined  in  definitions  Definition  4.7  and  Definition  4.9. 

Proof:  Essentially  the  same  as  the  proof  of  Proposition  C.26  for  Dom  ,  Cod  and  Mod  functors  over 
category /wre/p.  ,  ^ 

4.3,2  Category  dinterp  compared  with  category  Interp 

Because  dinterp  is  not  the  diagram  category  of  category  Interp  the  functors  Diagramize  and 
Colimit  defined  Section  3.4  Proposition  3.15  and  Proposition  3.17  cannot  be  directly  applied  to  categories 
Interp  and  dinterp.  These  functors  do  exist  between  the  two  categories  but  they  are  based  on  the  functors 
with  the  same  names  between  categories  Spec  and  dSpec  and  the  relationship  between  those  categories  and 
categories  Interp  and  dinterp. 

Proposition  4.12.  Category  Interp  has  a  functor  Diagramize  that  takes  category  Interp  objects  and  arrows 
to  category  dinterp  objects  and  arrows  by  using  the  category  Spec  functor  Diagramize  on  the  individual 
Spec  objects  and  arrows  making  up  an  Interp  object  and  arrow,  i.e.  Diagramize:  Interp^dlnterp. 

Proof:  An  object  in  Interp,  A=>B,  is  a  pair  of  Spec  morphisms  A“>B^<— B  with  a  common  codomain 
where  the  B’^<-B  arrow  is  a  definitional  extension.  An  Arrow  in  Interp  is  a  5-tuple  im  -  <A  =>  B,  C  =>  D, 
/:A->C,  giB'^-^D^  A:B->D>.  If  the  Spec  functor  Diagramize  is  used  on  the  individual  Spec  objects  and 
arrows  making  up  the  Interp  objects  and  arrows,  the  result  is  dinterp  objects  and  arrows.  The  interpretation 
A=>B  in  Interp  becomes  an  interpretation  in  dinterp  between  (singleton)  diagrams  A  and  B  with  (singleton) 
diagram  B''  as  the  mediator.  Sunilarly,  the  interpretation  morphism  im  in  Interp  becomes  an  interpretation 
morphism  in  dinterp. 
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It  is  obvious  that  the  identity  arrows  in  Interp  remain  identity  arrows  in  dinterp  as  they  do  so  for 
the  functor  Diagramize:Spec-^dSpec.  The  Diagramize:lnterp->dlnterp  functor  preserves  the  composition 
of  arrows  as  the  Diagramize'.Spec-¥dSpec  functor  does  so.  ^ 

A  dinterp  object  can  obviously  be  viewed  as  a  generalization  of  an  Interp  object  as  each  Spec 
interpretation  is  a  dSpec  interpretation  via  the  Diagramize  functor.  However  since  Diagramize  is  a  monic 
functor  and  Colimit  is  not,  fliere  are  many  dinterp  objects  for  each  Interp  object  and  therefore  dinterp 
objects  can  represent  more  information  (via  the  greater  structure  mherent  in  each  dinterp  object).  Chapter 
6  use  this  additional  structure  of  diagram  interpretations  to  represent  structured  design  information. 
Proposition  4.13.  Category  dinterp  has  a  functor  Colimit  that  takes  category  dinterp  objects  and  arrows  to 
category  dinterp  objects  and  arrows  by  using  the  category  dSpec  functor  Colimit  on  the  individual  dSpec 
objects  and  arrows  making  up  a  dinterp  object  and  arrow,  i.e.  Colimit:  dlnterp-^Interp. 

Proof:  If  each  of  the  dSpec  objects  and  arrows  making  up  a  dinterp  object  and  arrow  has  the 
Colimit.  dSpec-^Spec  functor  applied  to  it  the  result  is  an  Interp  object  and  arrow.  It  is  obvious  that 

identity  arrows  and  arrow  compositions  are  preserved. 

Every  dSpec  interpretation  (Category  dinterp  object)  has  an  associated  Spec  interpretation 
(Category  Interp  object)  via  the  Colimit:  dinterp— ^Interp  functor.  Thus  the  meaning  of  a  diagram 
interpretation  in  terms  of  the  class  of  models  and  reduct-functors  associated  with  the  individual  Spec 
diagrams  and  Spec  diagram  morphisms  can  be  defined  in  terms  of  Spec  interpretations  (Section  C.3.1). 

Any  implementation  of  (the  colimit  of)  the  target  diagram  of  a  dSpec  interpretation  can  be  extended 
(sometimes  mechanically)  to  irrqrlement  (the  colimit  of)  the  mediator  diagram  and  hence  (the  colimit  of) 
the  source  diagram. 

4.3.3  Diagram  interpretations  compared  with  diagram  refinement 

A  diagram  interpretation  can  also  be  viewed  as  a  generalization  of  diagram  refinement  (Definition 
C.28),  [SJ95],  [SLM98]  although  it  is  not  used  as  such  in  this  dissertation.  Intuitively,  since  diagram 
refinement  involves  a  single  change  in  structure  Gj— >62,  there  must  be  a  direct  embedding  of  the  somce 
diagram  structure  in  the  target  diagram  structure.  Because  a  diagram  interpretation  Gs^Gm<-Gt  involves 
two  changes  of  structure,  based  on  a  common  mediator  structure,  the  structure  of  the  target  diagram  may 
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bear  no  relationship  to  the  structure  of  the  source  diagram.  It  is  this  additional  change  in  shape  that  enables 
diagram  interpretations  to  express  more  refinements  than  diagram  refinement.  On  the  other  hand,  a 
diagram  refinement  can  be  expressed  as  a  collection  of  compatible  interpretations  [SLM98],  whereas 
diagram  interpretations  are  a  pair  of  diagram  morphisms,  one  of  which  is  a  definitional  extension. 
Developing  a  diagram  interpretation  that  takes  advantage  of  that  additional  structure  is  more  complicated. 

If  the  mediator  diagram  of  a  diagram  interpretation  is  restricted  to  be  the  same  shape  as  the 
domain  diagram  and  the  shape  morphism  from  the  codomain  diagram  to  the  mediator  diagram  is  restricted 
to  be  an  epimorphism,  then  a  diagram  interpretation  would  have  essentially  the  same  “refinement  power 
as  diagram  refinement  as  used  in  practice.  The  definition  of  diagram  refinement  allows  the  target  diagram 
to  contain  specifications  and  morphisms  that  are  completely  unrelated  to  the  refinement  operation  that  is 
taking  place.  In  contrast,  the  definition  of  a  diagram  inteipretation  allows  the  mediator  diagram  to  contain 
specifications  and  morphisms  tibat  are  completely  unrelated  to  the  refinement  operation  that  is  taking  place. 
In  practice,  with  either  definition,  such  additional  unneeded  specifications  and  morphisms  would  not  be 
used.  Thus  in  practice,  diagram  refinement  is  equivalent  to  diagram  interpretations  when  diagram 
interpretations  are  restricted  as  described  in  Figure  4-17. 


If  as  =  identity  morphism  and  Gj  =  epimorphism  then 
a  diagram  interpretation  is  roughly  equivalent  to  a 
diagram  refinement 

Figure  4-17.  Relationship  between  diagram  interpretation  and  diagram  reflnement 

Because  of  the  lack  of  limits  on  the  two  definitions,  the  target  diagram  for  diagram  refinement  vs. 
the  mediator  diagram  for  diagram  interpretations,  neither  construct  can  emulate  the  other.  However  for  the 
practical  uses  of  both  constructs,  diagram  refinements  are  a  subset  of  diagram  interpretations  thus  leading 
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to  the  remark  that  diagram  interpretations  are  a  generalization  of  diagram  refinement.  Figure  4-18  depicts 
how  diagram  refinements  that  do  not  contain  extraneous  specifications  and  morphisms  in  the  target 
diagram  can  be  lifted  to  be  a  diagram  interpretation. 


Diagram  refinement 
mSpec 


Spec 


Induced  by  the  collection  of 
5/?ec-arrows  to  (Med  o8)  (Gi) 

Q  Shape  identity  functors 
^  ^  Induced  by  the  inverse 

of  a:Gj->G2  and  by 
morphism  composition 


Diagramize  functors 
(diagramize  ©  Dj)  (Gj), 
(diagramize  o  Med  o6)  (Gj)  ,  and 
(diagramize  <>  D2)  (G2) 


'  ^  Source  ^  .  Target  _  Target  _  Source^ 

Spec  ■* - Spec~*  — Spec  ■* —  Spec^  Spec 

Diagram  Interpretation 
in  dSpec 


Figure  4-18.  Lifting  a  diagram  refinement  to  a  diagram  interpretation 


Again,  in  this  dissertation,  diagram  interpretations  are  used  as  a  mechanism  for  representing 
design  information  and  not  as  a  refinement  mechanism.  The  lumtations  of  diagram  refinement  as  a  method 
for  applying  design  information  were  presented  in  Section  2.5. 

4.4  Contributions  and  Future  Work 

Although  most  of  the  groundwork  for  category  dSpec  was  accomplished  in  Chapter  3,  the  notion 
of  a  category  of  diagrams  of  specifications  is  new  in  the  literature.  As  shall  be  demonstrated  in  later 
chapters,  this  category  enables  the  diagrammatic  stracture  of  a  requirement  specification  to  be  refined  in  a 
manner  that  is  superior  to  the  current  refinement  technique  of  using  diagram  refinement.  This  category  and 
the  functor  Colimit  enable  diagrams  of  specifications  and  morphisms  and  their  diagram  morphisms  to  be 
treated  as  specifications  and  morphisms  in  Spec.  This  makes  manipulating  Spec  diagrams  and  diagram 
morphisms  as  simple  (on  a  theoretical  level)  as  manipulating  specifications  and  specification  morphisms. 
This  also  enables  the  model  semantics  of  category  Spec  objects  and  arrows  to  be  lifted  to  category  dSpec 
objects  and  arrows. 
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A  second  contribution  of  this  chapter  is  the  diagram  parameterization  theory  developed  in  Section 
4.2,  which  is  the  focus  of  Chapter  5.  Although  many  notions  of  algebraic  specification  parameterization 
require  a  conservative  extension  to  exist  between  the  formal  parameter  and  the  body,  the  notion  of  all  of  the 
variable  parts  of  the  body  being  covered  by  the  parameter  is  formalized  in  this  dissertation  for  the  first  time. 
Reasoning  about  the  variable  parts  of  a  body  is  necessary  when  proving  that  a  refinement  of  a  body  does 
not  alter  its  relationship  with  the  “tme”  formal  parameters  of  a  body.  Also,  as  is  discussed  further  in 
Chapter  5,  the  notion  of  the  body  being  a  diagram  instead  of  a  single  specification  is  also  a  generalization 
of  other  notions  of  parameterization. 

Of  note  is  the  notion  that  diagram  morphisms  have  properties  such  as  being  a  conservative 
extension  or  a  definitional  extension  that  parallels  those  same  properties  in  category  Spec  arrows.  These 
properties  enable  dSpec  arrows  to  be  treated  in  a  similar  fashion  to  the  conservative  extension  (Section 
C.  1 .4)  and  definitional  extension  (Section  C.  1 .5)  Spec  arrows.  (A  conservative  extension  enables  all 
models  of  the  (colimit  of  the)  source  diagram  to  be  extended  so  that  they  are  models  of  the  (colimit  of  the) 
target  diagram  and  a  definitional  extension  enables  such  a  model  extension  to  be  uniquely  characterized.) 

A  final  contribution  is  the  notion  of  a  dSpec  interpretation  that  parallels  a  Spec  interpretation  and 
that  forms  the  basis  for  representing  design  information  in  Chapter  6.  While  a  Spec  interpretation  can 
insure  that  the  content  of  a  specification  is  refined,  a  dSpec  interpretation  can  insure  that  the  content  and 
structure  is  refined. 

Future  work  involves  developing  more  and  better  ways  for  determining  if  a  dSpec  morphism  (and 
hence  a  specification  morphism  via  the  colimit  functor)  is  a  conservative  extension  morphism  or  not.  Also 
more  and  better  ways  are  needed  for  determining  if  a  dSpec  object  (and  hence  a  specification  via  the 
colimit  functor)  has  variable  parts  or  not,  i.e.  determining  whether  a  specification  has  non-isomorphic 
models. 
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5  Parameterized  Diagrams 

This  chapter  develops  a  syntax  for  extending,  composing,  parameterizing  and  instantiating 
diagrams  by  building  upon  the  theory  of  parameterized  diagrams  developed  in  Section  3.5  and  Section  4.2. 
Parameterized  diagrams  are  shown  to  subsume  other  forms  of  algebraic  specification  parameterization  (as 
presented  in  Section  2.3  and  Appendix  E). 

Syntax  may  seem  like  a  minor  point,  but  it  is  at  the  heart  of  what  enables  people  to  diink  and 
operate  in  terms  of  a  higher  level  abstraction.  The  diagram  statement  transforms  a  diagram  construction 
operation  into  a  parameter  passing  operation.  It  does  not  allow  more  types  of  diagrams  to  be  created  than 
by  the  nodes  and  arcs  listing  construction  method.  However,  this  paradigm  shift  from  construction  to 
instantiation  hides  unnecessary  “implementation”  details  and  enables  the  specifier  to  think  about  the 
problem  being  specified  and  not  the  underlying  mechanism  (diagrams)  used  to  specify  the  problem. 

This  chapter  is  structured  as  follows.  Section  5.1  introduces  a  syntax  for  creating,  extending,  and 
composing  diagrams.  Section  5.2  defines  the  semantics  of  the  basic  diagram  statement,  which  can  only 
create,  combine  and  merge  diagrams,  and  demonstrates  its  use.  Section  5.3  defines  the  semantics  of  the 
parameterization  and  instantiation  aspects  of  the  diagram  statement  and  demonstrates  their  use.  Section  5.4 
compares  the  diagram  statement  developed  in  this  chapter  with  the  diagram  theory  presented  earlier. 

5. 1  The  Diagram  Statement  Syntax 

In  this  dissertation  it  is  diagrams  of  specifications  and  morphisms  that  are  parameterized,  as 
opposed  to  other  parameterization  research,  where  it  is  the  specifications  that  are  parameterized.  Passing 
parameters  to  the  parameterized  diagram  (instantiation)  involves  extending  the  diagram  so  that,  at  a 
minimum,  the  missing  parameterized  parts  of  the  diagram  are  filled  in.  The  completed  (instantiated) 
parameterized  diagram  is  the  structured  result  of  passing  parameters.  The  colimit  object  of  the  instantiated 
parameterized  diagram  is  the  unstructured  result  of  passing  parameters. 

The  diagram  statement  developed  in  this  chapter  enables  diagrams  to  be  extended,  parameterized, 
instantiated,  and  merged.  These  higher-level  operations  make  it  easier  for  the  diagram  structure  of  a 
specification  to  be  developed,  and  the  results  are  more  understandable  that  existing  methods. 
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1  import,  dicicr  i  .  u.j.aQ  i  j 

[  nodes  node  (  ,  node  ) *  ] 

f-varam-lis 

[  instantiate  (  instant  )  J 
snd- diagram 

t  ->  (  sort -name  |  op -name  )  (  .  (  sort -name  |  oo-name  )  )* 

diacr 

[  diacrram-name  :  1  diaaram-ref  [  [  11 

node  -> 

arc 

t  node -name  :  1  svec-ref 

r  arc -name  :  1  a-node-ref  ->  a-node-ref  :  sicr-mavvina-term 

sicr-mavvincr 

-term  {  [  sicr-mav-rule  (,  siQ-mav-rule  )  ]  ) 

sicr-mavvincr 

a-node-ref  )  * 

-arc -ref  )  * 

:  ]  diacrram-ref  [  a-varam-list  ] 


a-rparam-list  ->  (  a-sort-ref  |  a-ov-ref  )  [  ,  a-varam-list  ] 

cjualified-ref  ->  (  anv-ref  .  )  *  any-ref 

(subject  to  semantic/type  analysis  restrictions,  of  course) 


Key  for  the  grammar: 

Non-terminals  are  underlined  and  italicized 

[  ]  -  bold  square  brackets  mean  the  syntactic  contents  are  optional. 

(  )  *  -  bold  starred  parens  mean  zero  or  more  occurrences  of  the  contents. 

(  )  +  -  bold  plussed  parens  mean  one  or  more  occurrences  of  the  contents, 

j  -  bold  vertical  bar  means  either  side  but  not  both  sides  (exclusive  or). 


defined  by  the  grammar.  To  be  meaningful,  a  diagram  statement  must  pass  the  semantic  analysis 
requirements  as  well. 


A  non-terminal  ending  in  -name  is  syntactically  a  symbol  but  it  represents  a  declaration  of  the 
indicated  preface  type.  In  the  formal  parameter  list,  f-param-list.  the  declaration  is  “split”;  the  symbol  is 
known  but  its  “type”  (sort  or  operation)  is  not  known  until  the  same  symbol  is  used  elsewhere  in  the 
diagram  statement. 

A  non-terminal  ending  in  -ref  may  be  a  (qualified)  symbol  or  an  in-line  declaration  of  the 
indicated  type.  If  it  is  a  symbol,  it  is  required  to  be  of  the  type  indicated  by  the  preface  from  some 
declaration  of  that  symbol  (The  symbol  associated  with  a  spec-ref  must  be  the  same  as  one  that  was  in  a 
spec-name  declaration  in  the  enclosing  scope.) 

Any  -ref  non-terminal  preceded  by  a  may  be  a  qualified-ref  and  may  be  preceded  by  a 
collection  of  other  -refs  in  order  to  distinguish  it  from  other  -refs  with  the  same  symbol  name.  (A  sort— ref 
or  op-ref  may  be  qualified  by  node-refs  and  a  node-ref  may  be  qualified  by  diapram-refy  in  order  to 
reference  a  particular  object  unambiguously.) 

5.2  Semantics  of  the  Basic  Diagram  Statement 

This  section  defines  the  semantics  of  the  basic  diagram  statement.  The  basic  diagram  statement 

does  not  involve  parameterization  or  instantiation  but  does  enable  diagrams  to  be  combined  and  extended . 

The  grammar  for  this  limited  version  of  the  diagram  statement  is  depicted  in  Figure  5-2. 

diagram  ->  diagram  diagram-name  is 

[  import  diag  (  ,  diag  )*  ] 

[  nodes  node  (  ,  node  )*  ] 

[  arcs  arc  (  ,  arc  ) *  ] 

[  merge  merge  (  ,  merge  )*  ] 
end-diagram 

diag  ->  [  diagram-name  :  ]  diagram- ref 

node  ->  [  node -name  :  ]  spec-re£ 

arc  ->  [  arc -name  :  ]  cr-node-ref  ->  o-node-ref  :  sig-mavving- term 

sig-mavoing-  term  ->  {  [  sig-mao-rule  ( ,  sig-map-rule  )  *  ]  } 

sig-maouing-term  ->  morphism- ref 

sig-mav-rule  ->  (  op -ref  ->  ov-ref  )  \  (  sort -ref  ->  sort -ref  ) 

merge— >  a-node-ref  (  =  q-node-ref  )  * 

merge->  q-arc-ref  (  =  q-arc-ref  )* 

Figure  5-2.  Grammar  for  the  basic  Diagram  statement  (no  parameterization) 


no 


5.2.1  The  nodes  clause  and  the  arcs  clause 


The  nodes  clause  indicates  a  collection  of  nodes,  a,,  and  their  associated  Spec  objects.  The 
nodes  clause  indicates  which  specifications  are  to  be  included  in  a  diagram  (or  added  to  existing 
diagrams,  as  discussed  in  Section  5.2.2).  Each  node  has  the  indicated  name.  If  a  name  is  not  supplied  the 
node  has  the  name  of  the  indicated  specification.  All  nodes  must  have  unique  names. 

The  arcs  clause  indicates  a  collection  of  arcs,^;,  and  their  associated  Spec  arrows.  The  arcs 
clause  indicates  which  nodes  have  an  arc  between  them  and  the  underlying  specification  morphism 
associated  with  the  arc.  Each  arc  has  the  indicated  name  or  (if  a  name  is  not  supplied)  it  has  the  generic 
name  node-Xo-node. 

A  diagram  statement  that  only  has  the  nodes  and  arcs  clauses  produces  the  diagram 
Diggrgntnme:G^Spec  as  indicated  by  the  arcs  and  nodes  and  their  mapping  to  Spec  objects  and  arrows. 
The  shape  category  G  is  defined  by  the  listed  arcs  and  nodes  and  their  orientation,  Objects(G)  =  a,,  and 
Arrows(G)  =fi,  along  wifli  all  identity  arcs  and  then  closed  under  composition.  The  functor  Diagram-name 
is  the  pair  of  functions  <  Piagram-namenKjVrt,  Piagram-narneArmw  >  as  defined  by  the  association  between  a 
node  and  a  Spec  object,  and  an  arc  and  a  Spec  arrow.  The  identity  arrows  and  the  composition  of  two  given 
arrows  are  easily  determined. 

The  syntax  and  semantics  of  the  diagram  statement  that  contains  only  the  arcs  and  nodes 
clauses  is  essentially  identical  to  the  Specware  language  diagram  statement  described  in  Section  2.4  and 
Appendix  D.  An  example  of  a  diagram  statement  that  contains  only  an  arc  and  node  clause  is  diagram 

Map  depicted  in  Figure  5-3. 

5.2.2  The  import  clause 

The  import  clause  indicates  a  collection  of  Spec  diagrams  (or  dSpec  objects),  D/.  Each  of  these 
diagrams  are  to  be  extended  or  combined  into  a  larger  diagram,  thus  the  import  clause  enables  diagrams 
to  be  constructed  once  and  then  reused  and  extended  many  times.  With  the  import  clause,  a  diagram 
becomes  an  extendable  structure;  it  can  be  added  to  and  combined  with  other  diagrams. 

The  semantics  of  the  import  clause  is  defined  by  the  Join  operation  (Definition  3.22),  i.e. 
Join(D/).  If  the  same  diagram  is  imported  multiple  times,  it  must  be  given  different  names.  The  effect  of 
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the  import  clause  is  to  produce  a  base  diagvatn  of  the  diagram  statement  that  may  be  further  affected  by 
other  clauses  within  the  diagram  statement. 

Every  diagram  that  is  imported  has  an  extension  morphism  (Definition  3.21)  to  the  base  diagram 
of  the  diagram  statement.  Additional  nodes  (specifications)  can  be  added  to  the  base  diagram  by  using  the 
nodes  clause.  The  arcs  clause  can  be  used  to  connect  nodes  from  any  of  the  imported  diagrams  or  die 
nodes  from  the  nodes  clause.  Should  two  or  more  nodes  (that  originated  in  different  imported  diagrams) 
have  the  same  name,  the  diagram  names  can  be  used  to  qualify  (disambiguate)  the  node  names.  In  Section 
5.2.1  the  nodes  and  arcs  clauses  (witiiout  the  import  clause)  are  extending  the  empty  base  diagram. 

The  semantics  of  the  basic  diagram  statement  with  an  import  clause  is  the  same  as  without, 
namely  a  diagram  Diagram~name\G—>Svec  is  the  result.  Shape  G  is  constructed  first  via  the  join  semantics 
of  the  import  clause  and  then  extended  with  additional  arcs  and  nodes  from  those  associated  clauses  (and 
closed  under  arc  identity  and  composition). 

Figure  5-3  depicts  the  creation  of  a  reusable  diagram,  Map,  and  its  extension  to  diagram 
Map-from-Nat-to-Nat  (as  well  as  the  colimit  operation  that  flattens  the  diagram  into  a  single  specification). 
As  can  be  seen  in  Figure  5-3,  the  diagram  statement  supports  diagram  extensions. 


Diagram  Map  is 
nodes  Map, 

sl:One-Sort,  s2 :One-Sort 
arcs  sl->Map:  {X  ->  Dorn}, 
s2->Map;  {X  ->  Cod} 
end  -  diagram  _ _ _ 


Diagram  Map-from-Nat-to-Nat  is 
import  Map 

nodes  Dorn: Empty,  Cod: Empty 
arcs  map.sl->Dom:  {X  ->  Nat), 
map.s2->Cod:  {X  ->  Nat} 
end -diagram  _ _ 


Spec  Map-from-Nat-to-Nat  is 

Colimit  of  Map-from-Nat-to-Nat 


Figure  5-3.  Extending  an  existing  diagram 


112 


5.2.3  The  merge  clause 


The  merge  clause  enables  diagram  nodes  (or  arcs)  with  the  identical  underlying  Spec  objects 
(arrows)  to  be  combined  into  a  single  node  (or  arc).  For  two  or  more  nodes  (or  arcs)  to  be  merged  they 
must  have  the  same  underlying  Spec  object  (or  arrow).  Given  a  base  diagram  T>\G-^Spec,  formed  by 
importing  diagrams  and  then  extending  them,  the  merge  clause  with  its  collection  of  equivalenced  nodes 
and  objects  induces  an  epimorphism  ct:G— >G’  that  satisfies  the  properties  listed  in  the  definition  of  the  Fold 
operation  (Definition  3.23).  Thus  Fold(D,  a)  defines  the  semantics  of  the  merge  clause. 

In  Figure  5-4,  the  diagram  statement  is  used  to  develop  a  new  reusable  diagram,  Map-to-Map,  by 
composing  two  individual  Map  diagrams  (named  ml  and  m2  to  distinguish  them)  so  that  the  codomain 
object  of  the  ml  map  is  also  the  “domain”  of  the  m2  map.  The  Map-to-Map  diagram  is  then  extended  via 
the  method  already  described  using  Nat  as  the  “domain”,  “mediator”,  and  “codomain”  parameters  for  the 
larger  diagram.  Thus  the  reusable  library  diagram  Map  is  composed  with  itself  to  form  an  even  larger 
library  diagram,  Map-to-Map,  that  is  then  further  extended.  This  example  was  chosen  not  because  of  the 
usefulness  of  die  Map-to-Map  data  structure  per  se,  but  because  it  demonstrates  how  the  merge  clause 
works  as  well  as  demonstrating  how  diagram  composition  can  be  accomplished  despite  the  overloading  of 
specification  and  node  names  that  occurs  when  two  copies  of  the  same  diagram  are  imported  by  one 
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Map-to-Map-Nat  Map-to-Map 

(diagram  extension)  (merged  diagrams) 


5.3  Parameterization  and  Instantiation  Semantics  of  the  Diagram  Statement 


This  section  describes  the  semantics  of  the  diagram  statement  when  parameterization  and 
instantiation  are  used.  TTie  basic  diagram  statement  without  parameterization  enables  diagrams  to  be 
extended  and  combined.  Using  the  basic  statement  by  itself  means  that  diagrams  can  only  be  constructed 
using  a  diagram  building  analogy  (Figure  5-3  and  Figure  5-4)  where  arcs  and  nodes  are  being  added  to  an 
existing  diagram. 

The  code  in  Figure  5-5  depicts  two  different  diagram  constmctions  for  a  Set  of  items:  a  set  of  Nats 
and  a  set  of  Flags.  Note  that  the  code  for  die  two  diagram  statements  is  identical  except  for  the  nodes 
(specifications)  Empty  and  Flag  and  the  sorts  Nat  and  Flag  as  indicated  by  the  underlining  in  Figure  5-5. 
Note  also  tiiat  since  the  source  of  the  morphism  is  specification  One-Sort  in  both  cases,  half  of  the  code  for 
the  morphism  is  already  known,  namely  “X  -  >”.  Given  a  target  sort,  which  has  been  identified  as  coming 
from  a  particular  specification,  it  ought  to  be  possible  to  fill  in  the  underlined  pieces  in  the  code  in  Figure 


5-5.  This  observation  forms  the  basis  for  tiie  parameterization  and  instantiation  syntax  for  diagrams. 


diagram  Set-of-Nat  is 

Nodes  Set,  One-Sort,  Empty 
Arcs  One-Sort  ->  Set:  {X->E} 

One-Sort  ->  Empty :  {x->Nat} 
end -diagram  _ _ 


Set 


diagram  Set-of-Flag  is 

Nodes  Set,  One-Sort,  Flag 
Arcs  One-Sort  ->  Set:  {X->E} 

One-Sort  ->  Flag:  {X->Flaq) 
end  -  di  agram  _ _ 


Set 


Figure  5-5-  Diagram  similarities  using  the  diagram  construction  method 
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5.3.1  Formal  parameters 

The  foimal  parameters  of  a  parameterized  diagram  are  signature  elements,  not  diagrams, 
specifications,  or  nodes  and  arcs  (alfliough  the  signature  elements  are  representative  of  the  required  nodes 
and  arcs).  Figure  5-6  contains  the  grammar  for  the  parameterized  version  of  the  diagram  statement.  Note 
that  tile  formal  parameter  list  is  made  up  of  sort  names  and  operation  names.  Note  also  that  the  arc  clause 
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has  been  extended  to  include  a  new/different  “right  hand  side”  that  has  an  anonymous  arc  (no  arc  name  and 
no  specified  target  node).  This  anonymous  arc  is  used  to  define  the  “type”  (sort  or  operation)  of  the  formal 
parameter  signature  elements  as  well  as  whether  the  signature  elements  must  come  from  the  same 
specification  or  not.  The  anonymous  arc  can  only  be  instantiated  as  described  in  the  sequel;  it  cannot  be 
merged  (as  it  has  no  name  to  reference  it). 

diacrram  ->  diagram  dlacrram-name  [  [  f-varam-list  ]  ]  is 
[  import  diaa  ( ,  diaa  )*  ] 

[  nodes  node  (,  node  )*  ] 

I  arcs  arc  (,  arc  )*  ] 
t  instantiate  (  instant 
end-diagram 

f-oaram-list  {  sort -name  |  op -name  )  [  ,  f-param-list  ] 

diaa  [  diagram -name  :  ]  diaaram-ref  [  [  ]  ] 

arc  ->  a-node-ref  ->  ?  :  sia-mavDina- term 

sia-mawina-  term  ->  {  [  sia-mav-rule  ( ,  sia-maip- rule  )  *  ]  } 

sia-mapoina-  term  morphism -ref 

sia-map-rule  ->  (  op- ref  ->  op -ref  )  |  (  sort -ref  ->  sort -ref  ) 

instant-^  t  diagram -name  :  ]  diaaram-ref  [  a-varam-list  ] 

a-param-list  (  a-sort-ref  \  a -op -ref  )  [  ,  a-param-list  ] 

Figure  5-6.  Grammar  for  the  parameterized  Diagram  statement 

The  parameter  list  associated  with  a  diagram  statement  enables  a  diagram  to  be  parameterized  by 
sorts  and  operations  that  can  be  used  to  complete  a  signature  mapping  between  specifications.  For  each 
sort  or  operation  in  the  parameter  list  there  must  be  an  associated  by-name  reference  in  an  anonymous  arc 
declaration  of  the  following  form: 

arc  ->  node -ref  ->  ?  :  sia-mappina- term. 

In  an  anonymous  arc,  the  source  node  is  known  but  the  target  node  and  morphism  to  the  target  node  are  not 
known.  Since  the  source  node  is  known,  however,  the  source  sorts  and  operations  in  the  underlying 
signature  mapping  are  known  as  well,  thus  the  source  signature  references  on  the  left  of  the  “-  >”  symbol  in 
the  following  syntax  are  known, 

sia-map-rule  (  op -ref  ->  op -ref  )  |  (  sort -ref  ->  sort-re_f  ), 
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but  the  target  signature  references  on  the  right  are  not  known.  Each  target  reference  in  the  signature 
mapping  of  an  anonymous  arc  must  match  up  by  name  with  a  formal  parameter  list  item.  In  this  case  the 
type  of  the  source  reference  (sort  or  op)  indicates  the  type  of  the  target  reference  and  the  type  of  the 
associated  formal  parameter  list  item. 

The  formal  parameters,  a  collection  of  sort  and  operation  names,  represent  missing  Spec  arrows 
and  objects.  The  known  nodes,  arcs,  and  imported  diagrams  of  a  parameterized  diagram  statement  produce 
a  diagram,  dia2ram-name:G—>Spec.  the  same  as  die  non-parameterized  version  above  did.  However,  shape 
G  along  with  the  unknown  arcs  and  target  nodes  (based  on  the  parameterization)  also  define  a  shape  G’  and 
a  shape  monomorphism  a:G— >G’.  Thus  the  semantics  of  a  diagram  statement  with  formal  parameters  is  a 
parameterized  diagram,  <  diap-am-name:G-^Svec^  a:G-»G’  >  (Definition  3.24).  The  diagram 
diagram-name:G-^Spec  is  referred  to  as  the  underlying  diagram  of  the  parameterized  diagram  or  the  fixed 
part  of  the  parameterized  diagram.  The  shape  monomorphism  a  indicates  what  additional  arcs  and  nodes 
(and  associated  Spec  objects  and  arrows)  are  needed  to  instantiate  the  diagram. 

Figure  5-7  depicts  a  diagram  parameterization  involving  the  specification  Set.  The  semantics  of 
the  code  in  Figure  5-7  is  the  parameterized  diagram,  <Set:G— a>,  where  diagram  Set  is  the  diagram 
with  a  single  arrow  fi:om  specification  One-Sort  to  specification  Set,  and  a:G^G’  is  the  shape 
monomorphism  that  extends  shape  G  with  ah  additional  node,  and  an  arc  to  that  node  as  depicted  on  the 
right  in  Figure  5-7. 


Map 

Figure  5-7.  Formal  parameter  example 

Figure  5-8  depicts  an  example  of  diagram  parameterization  with  multiple  parameterized  objects. 
Note  that  the  names  dom  and  cod  are  multiply  defined  in  the  parameterization.  In  the  first  two  arcs,  dom 
and  cod  are  sorts  within  the  (target)  Map  specification.  In  the  last  two  (anonymous)  arcs,  dom  and  cod  are 
placeholders  for  the  actual  signature  elements  as  the  target  specification  is  not  yet  known.  Duplicate  names 
such  as  these  easily  coexist  in  the  same  diagram  statement. 


diagram  Set  [Elem]  is 
Nodes  Set,  One -Sort 
Arcs  One-Sort  ->  Set:  {X->E} 

One-Sort  ->  ?:  {x  ->  Elem} 
end -diagram 
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Diagram  Map  [dom,  cod]  is 
Nodes  Map, 

sl:One-Sort,  s2 lOne-Sort 
Arcs  si  ->  Map:  {X”>dom} 
s2  ->  Map:  {X~>cod} 
si  ->  ?:  {X-->dom} 
s2  ->  ?:  {X->cod} 
end  -di  agram  _ _ 


si; One -Sort  s2; One -Sort 


Figure  5-8.  Map  parameterized  diagram  example 


5.3.2  The  instantiate  clause 

In  order  to  instantiate  a  parameterized  diagram  one  must  first  import  the  parameterized  diagram. 
The  import  clause  permits  parameterized  diagrams,  indicated  by  the  empty  brackets,  [  ],  as  well  as 
normal  diagrams  to  be  imported.  The  semantics  of  the  import  clause  have  not  been  changed  from  the 
discussion  in  Section  5.2.2.  When  a  diagram,  including  the  “fixed”  diagram  underlying  a  parameterized 
diagram,  is  imported  it  becomes  part  of  the  diagram  being  produced  by  the  diagram  statement  by  the  join 
semantics  (Definition  3.22).  Each  imported  parameterized  diagram  must  be  instantiated  using  the 
instantiate  clause.  (Leaving  the  brackets  off  of  an  imported  parameterized  diagram  indicates  the 
fixed  portion  of  the  parameterized  diagram  is  imported,  and  no  instantiation  is  needed.) 

In  the  instantiate  clause,  actual  sorts  and  operations  are  passed  to  the  parameterized  diagram 
via  the  sequence  former  “[  ]”.  By  qualifying  the  passed  signature  elements  imtil  their  parent  specifications 
(and  nodes)  can  be  unambiguously  determined,  the  signature  elements  carry  with  them  the  target 
specification  (and  node)  information  for  the  anonymous  arc  being  instantiated.  All  the  signature  elements 
associated  with  one  of  the  unknown  arcs  within  the  parameterized  diagram  being  instantiated  must  come 
from  the  same  specification  associated  with  the  same  node.  If  they  do,  the  passed  signature  elements 
themselves  complete  the  signature  mapping  in  the  morphism  associated  with  this  arc  and  the  node  they 
come  from  becomes  the  target  node  of  that  mapping.  The  instantiated  arc  is  named  in  the  generic  way  and 
the  unknown  target  node  of  the  arc  assumes  the  name  of  the  “indirectly”  passed  node. 

Because  the  imported  diagrams  and  nodes  and  arcs  were  present  prior  to  instantiation  (so  to  speak) 
in  the  semantics  of  the  diagram  statement,  instantiation  can  be  viewed  as  forming  arcs  between  existing 
nodes  in  the  base  diagram.  If  the  instantiation  is  named,  then  the  nodes  and  arcs  of  that  sub-diagram  can  be 
referenced  by  the  instantiation  name. 
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The  key  to  being  able  to  use  signature  elements  as  parameters  is  to  ensure  that  the  signature 
elements  are  unambiguously  attributed  (sourced)  to  a  single  node  in  the  diagram.  It  may  be  possible  to 
construct  specifications  and  diagrams  such  that  two  signature  elements  within  a  single  specification  have 


the  same  name  and  cannot  be  distinguished.  The  use  of  node  names  during  construction  for  specifications 
and  diagrams  can  eliminate  such  an  occurrence.  Given  that  the  parameterized  diagrams  and  specifications 
used  by  an  instantiate  statement  have  been  properly  constructed,  then  the  signature  elements  within 


them  can  be  unambiguously  sourced  when  instantiating  the  parameterized  diagram. 

The  result  of  a  diagram  statement  with  an  instantiate  clause  is  a  diagram.  That  portion  of 
the  overall  diagram  that  corresponds  to  a  strict  instantiation  of  the  parameterized  diagram  is  a  sub-diagram 
of  the  overall  diagram.  Figure  5-9  depicts  three  different  example  instantiations  of  the  Map  parameterized 
diagram.  In  the  first  example,  die  Map  parameterized  diagram  is  instantiated  using  two  different 
nodes/specifications.  In  the  second  example,  the  Map  parameterized  diagram  is  instantiated  using  a  single 
node/specification.  In  the  last  example,  the  Map  parameterized  diagram  is  instantiated  using  two  different 
nodes  with  the  same  underlying  specification. 


diagram  Map-Nat-to-Flag  is 
import  Map[] 
nodes  Empty,  Flag 
instantiate 

Map [Empty. nat,  flag] 
end ~ diagram 


diagram  Map-Flag-to-Flag-1  is 
import  Map[] 
node  Flag 
instantiate 

Map [flag,  flag] 

end”  diagram  _ _ 


Diagram  Map-Flag-to-Flag-2  is 
import  Map [  ] 
node  fl:Flag,  f2:Flag, 
instantiate 

Map [f 1 . flag,  f 2 . flag] 
end “diagram 


si: One -Sort  s2: One -Sort 


Map 


Figure  5-9.  Three  instantiations  of  the  Map  parameterized  diagram 
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5.3.3  Nested  parameter  passing  semantics 

The  instantiations  in  the  examples  so  far  have  been  of  a  parameterized  diagram  being  instantiated 
by  one  or  more  nodes.  Nested  parameter  passing  enables  one  parameterized  diagram  to  be  instantiated  by 
another  (parameterized)  diagram.  This  enables  parameterization  and  instantiation  to  be  used  for 
constructing  diagrams  representing  complex  nested  data  structures.  Figure  5-10  dqjicts  a  diagram  of  a  map 
from  a  nat  to  a  set  of  flags  constracted  using  only  specifications  and  morphisms.  Note  how  having 
specifications  and  morphisms  as  die  largest  building  blocks  makes  constructing  even  a  simple  diagram 
difficult. 


Map 


Figure  5-10.  Map  to  Set  diagram  using  the  diagram  construction  method 

In  contrast,  the  same  Map-Nat-to-Set-of-Flag  diagram  in  Figure  5-10  is  constracted  in  two  distinct 
ways  in  Figure  5-11.  In  the  first  example,  the  diagram  is  constracted  with  two  separate  instantiations.  The 
second  instantiation  is  to  die  sort  Set  is  specification  Set  ill  the  (now  instantiated)  parameterized  diagram 
Set.  In  the  second  example,  the  Set  instantiation  is  done  in-line.  Comparing  the  examples  in  Figure  5-1 1 
with  the  diagram  statement  of  Figure  5-10  shows  how  parameterization  and  instantiation  make  it  easier  to 
understand  what  data  structure  is  being  constracted. 


diagram  Map-Nat-to-’Set-of -Flag-1  is 
import  Map  []  ,  Set  [] 
nodes  Empty,  Flag 
instantiate 

Set  [Flag] 

Map  [Empty . nat ,  Set] 

end-diagram _ _ _ _ _ 

diagram  Map-Nat-to-Set-of -Flag-2  is 
import  Map[],  Set  []  ,  Empty,  Flag 
instantiate 

Map  [Empty. nat.  Set [Flag] .Set] 
end-diagram _ _ _ _ 

Figure  5-11.  Map  to  Set  diagram  using  nested  instantiation 


Diagram  Map-Nat-to-i 

Set-of-Flag  is 

Nodes  Map,  Set,  Flag,  Empty, 

sl:One-Sort 

,  s2: One- Sort, 

s3 : One -Sort 

Arcs  si  ->  Map: 

{X->Dom} 

si  ->  Empty: 

{X->Nat} 

s2  ->  Map: 

{X->Cod} 

S2  ->  Set: 

{X->Set} 

s3  ->  Set: 

{X->E} 

S3  ->  Flag: 

{X->Flag} 

end -diagram 
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5.3.4  Partial  instantiation  semantics 


Instantiating  a  parameterized  diagram  is  not  an  all-or-nothing  proposition  as  it  is  with  notions  of 
parameterized  specifications  in  the  literature.  A  parameterized  specification  can  be  partially  instantiated  by 
passing  to  it  formal  parameters  of  the  enclosing  parameterized  diagram.  A  new  “larger”  parameterized 


diagram  is  created  by  partially  instantiating  one  or  more  other  parameterized  diagrams.  The  formal 
parameters  of  the  enclosing  parameterized  diagram  are  defined  either  by  anonymous  arcs  (as  described  in 


Section  5.3.1)  or  they  are  defined  by  passing  through  the  “type  information”  of  the  formal  parameters  of  a 
parameterized  specification  that  is  being  partially  instantiated.  An  obvious  requirement  for  signature 
element  parameters  is  that  if  there  are  a  number  of  formal  sorts  and  operations  associated  with  a  single 
unknown  arc,  then  either  all  or  none  of  them  must  be  instantiated  with  actual  sorts  and  operations,  or 
passed  up  as  parameters  to  the  next  level. 

In  Figure  5-12,  the  Map  parameterized  diagram  is  partially  instantiated  with  the  fixed  part  of  the 
Set  parameterized  diagram.  The  Set  parameterized  diagram  is  not  instantiated  at  all.  The  formal 
parameters  of  the  Map-to-Set  parameterized  diagram  are  defined  based  on  the  parameters  of  the  Map  and 
Set  parameterized  diagrams  that  were  not  instantiated. 


diagram  Map-to-Set  [A, B]  is 
import  Map  []  ,  Set  [] 
instantiate 

Map [A,  Set  [B]  . Set] 
end-diagram 


diagram  Map-Nat-to-Set-of-Flag-3  is 
import  Map-to-Set [] 
nodes  Empty,  Flag 
instantiate 

Map-to-Set [Empty. nat.  Flag] 
end-diagram  _ 


sl:One-Sort  s2;One-Sort  s3:One-Sort 


Figure  5-12.  Partial  instantiation  example 


5.3.5  Recursive  parameter  passing  semantics 

Recursive  parameter  passing  involves  instantiating  two  or  more  parameterized  diagrams  with  each 
other’s  “body”  specifications.  Recursive  parameter  passing  is  needed  in  order  to  construct  a  recursive  data 
stracture. 
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The  example  depicted  in  Figure  5-13  develops  a  recursive  data  structure  using  the  diagram 
construction  method.  The  coproduct  and  pair  (tuple)  specifications  may  be  built  into  the  language  as  a 


primitive  (they  are  in  die  Specware  language).  However,  the  code  for  them  is  included  in  Figure  5-13  in 
order  to  make  the  example  easier  to  understand.  The  specifications  in  Figure  5-13  can  be  considered  to  be 
reusable  library  specifications  while  the  diagram  statement  cannot  be,  as  it  has  already  been  instantiated  . 
The  colimit  specification  of  the  Recursive-Pairs-of-Nats  diagram  contains  a  sort  Cop  and  a  sort  Pair.  The 
sort  Cop  is  a  coproduct  fiiat  can  be  the  sort  Pair  or  the  sort  Nil.  The  sort  Pair  is  a  tuple  that  contains  a  Nat 
and  a  Cop.  If  <,>  is  used  to  designate  the  elements  of  a  pair  flien“<6,  <2,  <1,  nil»>”isan 


example  of  an  “elemenf’  of  the  recursive  data  stracture  formed  in  Figure  5-13. 


spec  coproduct  is 

spec  pair  is 

sort  cop.  A,  B,  A-cop,  B-cop 

sort  pair.  A,  B 

op  embed-A:  A  ->  cop 

op  make -pair:  A,B  ->  pair 

op  embed”B:  B  ->  cop 

op  Project -A:  pair  ->  A 

op  is -A:  cop  “>  boolean 

op  Project -B:  pair  ->  B 

op  iS“B:  cop  “>  boolean 

constructors  {make -pair} 

op  get -A;  A-cop  ->  A 

construct  pair 

op  get-B:  B-cop  ->  B 

Forall  a:A,  b:B 

constructors  {embed-A,  embed-B} 

ax  proj ect-A (make-pair (a, b) )  =  a 

construct  cop 

ax  project-B (make-pair (a, b) )  =  b 

sort -axiom  A-cop  =  cop  |  is -A 

end- spec 

sort-axiom  B-cop  =  cop  |  is-B 

spec  nil  is 

Forall  a:A,  b:B 

sort  nil 

ax  get-A(i (embed-A (a) ) )  =  a 

op  nil:  ->  nil 

ax  get-B  ( i (embed-B (b) ) )  =  b 

constructors  {nil}  construct  nil 

end- spec 

end- spec 

Diagram  Recursive-Pairs-of-Nats  is 
nodes  cop : coproduct , 

pair,  nil,  Empty, 

Tl: One -Sort,  T2: One -Sort, 
PI: One -Sort,  P2: One -Sort 
arcs  Tl->cop:  {X->a}, 

T2->cop:  {X->B) , 

Tl->nil:  {X->nil) 

T2->pair:  {X->pair}, 

Pl->pair:  {X  ->  a}, 

P2->pair:  {X->  b}, 

Pl->Empty:  {X->  Nat} 
P2->COp:  {X->  cop}, 

end-diagram  _ 


Tl : One - Sort  T2 : One - Sort 


Nil  H 


Empty 


Figure  5-13.  Recursive  data  structure  using  the  diagram  construction  method 


The  same  recursive  data  structure  can  be  coded  using  parameterized  diagrams  and  the 
instantiate  statement  in  a  more  imderstandable  fashion.  In  Figure  5-14  the  parameterized  diagrams 
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for  a  coproduct  and  a  Pair  are  constructed.  Then  the  parameterized  diagram  Recursive-Pair  is  constructed 


in  a  way  that  leaves  the  actual  “data  type”  portion  of  the  abstract  data  structure  as  a  parameter.  These  three 
diagrams  can  be  considered  to  be  reusable  parameterized  diagrams  that  could  be  placed  in  a  library. 

Finally,  the  parameterized  diagram  Recursive-Pair  is  instantiated  with  Nats  so  that  the  resulting  diagram 
matches  that  of  Figure  5-13.  Once  again,  when  the  method  of  construction  with  reusable  parameterized 
diagrams  (Figure  5-14)  is  compared  to  the  construction  method  without  parameterized  diagrams  (Figure 
5-13),  it  is  easy  to  see  how  parameterized  diagrams  and  the  diagram  statement  enable  a  specifier  to  work  on 


a  higher  level  of  abstraction. 


diagram  coproduct  [A,B]is 
nodes  cop : coproduct , 

Tl: One -Sort,  T2 : One -sort 


arcs  Tl->cop: 
T2->cop : 
Tl->?: 
T2->?: 
End “diagram 


{X->A}, 
{X->B) , 
{X->A}, 
{X->B} 


Diagram  Recursive-pairs [Ele]  is 
Import  coproduct  [],  pair[] 
nodes  nil 
Instantiate 

coproduct [nil, pair] 
pair [Ele, cop] 

end -diagram  _ 


Diagram  Recursive-Pairs-of -Nats  is 
import  Recursive-pairs [] 
nodes  Empty 
instantiate 

Recursive-pairs [Empty. Nat] 
end-diagram  _ _ 


Tl : One - Sort  T2 i One - Sort 


Tl : One - Sort  T2 : One - Sort 


Figure  5-14.  Recursive  data  structure  using  diagram  instantiation 
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Recursive -pairs -of -Nats  Recursive -pairs  Pair  diagram  CoProduct  diagram 


5.3.6  Syntactic  sugar  and  Petri  Net  example 


In  a  sense  the  import  clause  is  redundant  for  importing  parameterized  diagrams  (but  not  for  non- 
parameterized  diagrams).  As  each  imported  parameterized  diagram  must  be  instantiated  within  the 
diagram  statement,  the  “inq)orted”  parameterized  diagrams  can  be  determined  by  the  contents  of  the 
instantiate  clause  alone.  The  only  requirement  is  that  if  the  same  parameterized  diagram  is 
instantiated  more  than  once,  then  each  instantiation  must  be  given  a  umque  name.  Tins  provides  the 
equivalent  semantics  to  importing  the  diagram  multiple  times  in  the  import  clause  and  naming  it 
differently  each  time.  Figure  5-15  uses  these  alternate  semantics  to  develop  the  abstract  requirements  for  a 
Petri  Net  data  structure.  (The  code  in  Figure  5-15  assumes  that  parameterized  diagrams  for  Set,  Bag,  Pair 
and  Map  already  exist,  which  is  reasonable  considering  their  utility.)  It  is  straightforward  to  see  how  using 
parameterized  diagrams  makes  it  easier  to  constmct  large  complex  objects  and  to  understand  what  has  been 
constmcted  (compare  Figure  5-15  with  Appendix  D). 


Diagram  Petri-Net  is 

nodes  Empty,  Place,  Transition 
instantiate 

Set-of -Places :  Set [Place] 

Set-of -Transitions :  Set [Transition] 

Input-Arc:  Pair [Place,  Transition] 

Output -Arc :  Pair [Transition,  Place] 

Bag-of -Input-Arcs :  Bag [Input-Arc . Pair] 

Bag-of -Output-Arcs :  Bag [Output-Arc . Pair] 

Map-of -Markings:  Map [Place,  Empty. Nat] 

end- diagram _ _ _ _ _ 

Figure  5-15.  Petri  Net  diagram  created  using  parameterized  diagrams 


5,4  Diagram  Statement  Compared  with  Parameterized  Diagram  Theory 

How  does  the  syntax  and  semantics  of  the  diagram  statement  developed  in  this  chapter  compare 
with  the  diagram  theory  presented  in  Chapter  3  and  Chapter  4?  The  theory  requires  that  there  be  a  formal 
parameter  part  and  a  body  part  with  a  diagram  morphism  between  them,  yet  the  diagram  statement  appears 
to  make  no  such  distinction. 

The  diagram  statement  defined  in  this  chapter  only  allows  parameterized  diagrams  with  lower 
bound  requirements  (Section  3.5.7  and  Section  4.2).  As  such,  the  anonymous  arcs  can  be  used  to  induce  a 
separation  of  the  fixed  part  of  the  parameterized  diagram  into  a  formal  parameter  part  and  a  body  part 
(Section  4.2.3,  Figure  4-11).  The  formal  parameter  part  is  the  source  nodes  of  the  anonymous  arcs  (and  the 
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arcs,  if  any,  between  these  nodes)  that  serve  as  the  lower  bound  requirement  for  the  variable  part.  The 
body  consists  of  all  of  the  rest  of  the  nodes  and  the  arcs  between  them.  Connecting  the  formal  parameter 
part  and  the  body  should  be  a  collection  of  morphisms  that  can  be  used  to  induce  a  diagram  morphism 
between  the  formal  parameter  part  and  the  body  part.  Instantiating  the  parameterized  diagram  can  also 
induce  a  diagram  morphism  between  the  formal  parameter  diagram  and  the  (induced)  actual  parameter 
diagram. 

If  one  examines  the  various  parameterized  diagrams  developed  in  this  chapter,  in  each  case  it  is 
easy  to  see  how  this  partition  (Definition  3.20)  of  the  parameterized  diagram  can  be  accomplished.  For 
example,  the  parameterized  diagrams  in  Figure  5-14  can  be  partitioned  as  depicted  in  Figure  5-16. 


Tl: One -Sort 


T2: One -Sort  j 


fx  ->  A) 


Jx  ->  B} 


I  M  i 

\  CoProduct  ] 


PI: One -Sort 


P2: One -Sort | 


[  Pair 


Tl: One -Sort  T2: One -Sort 


|{x->pairJX^  > 

[  PI  :One^ort'  j  f^^ne-Sort 

ill 

- 3^  /  /  CoProduc^ 

{x->JSlenj} \  /I  / 

^  ^^air 


Figure  5-16.  Induced  partitioning  of  a  parameterized  diagram 
This  partitioning  of  the  parameterized  diagram  into  a  formal  parameter  part  and  a  body  part  cannot 


always  be  induced  for  reasons  discussed  in  Section  3.4.4.  However,  whether  or  not  such  a  partition  is 
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possible  can  be  checked  syntactically  via  die  partition  construction  algorithm  presented  in  Section  3.4.4. 

The  existence  of  the  diagram  morphisms  from  the  formal  parameter  diagram  to  the  body  diagram  (and  from 
the  formal  parameter  diagram  to  the  actual  parameter  diagram)  can  be  enforced  as  a  requirement  of  the 
diagram  statement  via  semantic  analysis  if  desired. 

5.5  Contributions 

The  contributions  of  this  chapter  include  the  use  of  Spec  diagrams  as  reusable  extendable  objects 
in  a  software-engineering  context.  The  syntax  for  creating  and  instantiating  parameterized  diagrams 
bridges  die  gap  between  the  underlying  theory  and  its  use  in  a  software-engineering  environment.  The 
syntax  of  the  Hiagram  statement  is  defined  in  terms  of  the  parameterized  diagram  dieory  developed  in 
Section  3.5  and  Section  4.2  and  is  demonstrated  to  be  capable  of  single  parameterization,  multi¬ 
parameterization  and  diagram  parameterization  as  well  as  nested  and  recursive  instantiation.  In  addition, 
the  parameterized  diagram  statement  is  demonstrated  to  be  capable  of  being  partially  instantiated  so  that 
larger  parameterized  diagrams  can  be  constructed  from  smaller  parameterized  diagrams. 

No  longer  are  specifications,  morphisms  and  interpretations  the  largest  reusable  objects  for 
creating  Spec  diagrams  The  use  of  parameterized  Spec  diagrams  enables  Spec  diagrams  to  be  created 
iiRing  instantiation,  which  is  arguably  a  more  natural  and  higher-level  diagram  development  method  than 
the  Hiagram  construction  method  of  listing  the  diagrams  nodes  and  arcs.  While  previous  research  in 
parameterization  of  algebraic  specifications  has  focused  on  how  a  single  specification  can  be  parameterized 
by  a  variety  of  different  formal  parameter  schemes  (presented  in  Section  2.3  and  Appendix  E),  diagram 
parameterization  has  been  shown  to  subsume  these  other  notions  of  algebraic  specification 
parameterization  while  adding  additional  capability.  Specifically,  parameterized  diagrams  enable  the  body 
of  a  parameterized  object  to  be  a  diagram  of  specifications  and  morphisms  instead  of  a  single  specification 
and  the  instantiation  semantics  result  in  a  diagram  instead  of  a  single  specification. 
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6  Representing  and  Applying  Design  Information 

In  order  to  refine  a  requirement  specification  that  has  structure,  meaning  it  was  developed  by 
combining  many  smaller  specifications,  one  has  to  be  able  to  deal  directly  with  that  structure.  Diagram 
interpretations  provide  the  foundation  for  representing  and  applying  structured  design  mformation.  This 
chapter  combines  the  concept  of  parameterized  diagrams  developed  in  Section  4.2  with  the  notion  of 
diagram  interpretations  developed  in  Section  4.3,  enabling  the  refinement  of  parameterized  diagrams  to  be 
correctly  represented.  A  representation  method  for  design  information  is  incomplete  without  an  application 
mefliod.  This  chapter  also  adapts  the  dSpec  pushout  operation  developed  in  Section  3.6  in  order  to  apply 
the  structured  design  information.  The  representation  technique  for  design  information  and  its  apphcation 
method  are  shown  to  be  able  to  correctly  represent  the  refinements  of  parameterized  diagrams  and  to  be 
able  to  correctly  apply  that  information  to  the  structure  of  a  requirement  specification.  The  design 
information  representation  technique  and  application  method  are  shown  to  solve  the  problems  with  using 
Spec  interpretations  and  diagram  refinement  as  the  means  for  representing  and  applying  design 
information,  respectively,  as  presented  in  Section  2.5 

This  chapter  is  structured  as  follows.  Section  6.1  defines  how  design  information  can  be 
represented  using  diagram  interpretations  that  have  several  additional  requirements  placed  on  them 
depending  on  the  class  of  design  information  being  represented.  Section  6.2  defines  how  design 
information  can  be  applied  to  requirement  specifications  as  well  as  how  it  can  be  composed  with  other 
design  information.  Section  6.3  describes  some  of  the  ways  that  the  representation  of  design  mformation 
can  be  simplified  and  still  be  correctly  applied  and  composed.  Section  6.4  provides  an  example  of  a 
requirement  diagram  being  refined  by  applying  a  sequence  of  design  decisions.  Diagram  interpretations  are 
shown  to  subsume  interpretations  and  diagram  refinement  by  solving  the  issues  presented  in  Section  2.5 
and  offering  greater  assurance  that  design  mformation  is  being  represented  and  applied  correctly. 

6. 1  Representing  Design  Information 

In  diagram  refinement,  design  information  is  represented  as  Spec  interpretations  and  the 
refinement  of  a  diagram  is  based  on  a  collection  of  compatible  Spec  interpretations  fi*om  the  specifications 
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making  up  the  diagram.  Thus  the  structure  of  the  requirement  specification  pre-determines  the  structure  of 
the  class  of  possible  implementations.  In  order  to  break  the  structure  dependencies  inherent  in  diagram 
refinement,  an  interpretation  mechanism  is  needed  that  can  refine  diagrams  of  specifications  in  such  a  way 
that  a  compatible  family  of  (parallel)  interpretations  is  not  required. 

A  diagram  interpretation  can  be  viewed  as  a  refinement  mechanism  that  demonstrates  how  a 
particular  Spec  diagram  can  be  extended  in  order  to  implement  another  Spec  diagram.  This  refinement  is 
independent  of  the  structures  of  the  source  and  target  diagrams,  as  the  mediator  diagram  intercedes.  A 
diagram  interpretation  can  also  be  viewed  as  design  information  that  can  be  applied  to  a  requirement 
specification.  Unfortunately  the  definition  of  a  diagram  interpretation  given  in  Definition  4.7  is  insufficient 
to  ensure  that  design  information  can  be  adequately  represented  and  applied.  Specifically,  it  has  no  notion 
of  parameterization,  which  should  be  an  integral  part  of  the  construction  and  refinement  of  diagrams  that 
were  created  via  parameterization  and  instantiation.  In  order  to  rectify  that  lapse,  three  different  classes  of 
design  information  are  defined  in  this  section  along  with  the  additional  properties  that  are  required  of  a 
diagram  interpretation  to  insure  that  such  design  information  is  correctly  represented  and  applied. 

6.1.1  Classes  of  design  information 

The  three  different  classes  of  design  information  defined  in  this  section  are  simple  design 
information,  parameterized  design  information,  and  constrained  parameterized  design  information.  All  of 
them  require  additional  properties  above  and  beyond  those  given  in  the  definition  of  a  diagram 
interpretation  in  order  for  diagram  interpretations  to  represent  and  apply  the  design  mformation  correctly. 
The  additional  properties  needed  to  represent  these  classes  of  design  information  are  presented  in  this 
section.  Section  6.1.2  provides  examples  of  these  classes  of  diagram  interpretations. 

Simple  design  information 

Simple  design  information  is  characterized  by  only  having  a  single  model  (class  of  isomorphic 
models)  associated  with  it.  This  class  of  design  information  is  represented  by  a  diagram  interpretation 
where  the  domain  diagram  of  the  interpretation  has  no  variable  parts.  An  example  of  this  is  the 
interpretation  Flag->FlagAsNat^d-Nat.  The  additional  property  required  by  a  simple  diagram 
interpretation  is  that  the  mediator  and  codomain  diagrams  of  the  diagram  interpretation  must  also  have  no 
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variable  parts.  A  diagram  interpretation  with  these  properties  is  termed  a  simple  diagram  interpretation. 
Such  a  diagram  interpretation  ensures  that  once  a  single  model  has  been  established,  one  cannot  introduce 
extraneous  “variability”. 


Parameterized  design  information 

Parameterized  design  information  is  characterized  by  being  associated  with  a  parameterized 
diagram.  This  class  of  design  information  is  represented  by  a  diagram  interpretation  where  the  domain, 
mediator  and  codomain  diagram  making  up  the  diagram  interpretation  can  be  induced  to  have  a  body  part 
and  a  formal  parameter  part.  An  example  of  this  is  the  diagram  interpretation  Set->SetAsBag<“d*“Bag  in 
Figure  4-14.  The  following  properties  (which  are  also  depicted  in  Figure  6-1)  are  required  by 


parameterized  diagram  interpretations: 

1 .  The  entire  diagram  interpretation  must  be  capable  of  being  (re)partitioned  so  that  the  domain, 
mediator  and  codomain  diagrams  have  separate  formal  parameter  and  body  diagrams. 

2.  In  die  (re)partition,  the  formal  parameter  diagrams  form  a  diagram  interpretation  and  the  body 
diagrams  form  a  diagram  interpretation  and  there  exists  a  (conservative)  diagram 
interpretation  morphism  between  the  two. 

3.  The  diagram  morphism  from  the  domain  formal  parameter  diagram  to  the  mediator  formal 
parameter  diagram  must  be  a  definitional  extension  morphism  (typically  the  identity 
morphism). 


Figure  6-1.  Required  properties  of  a  parameterized  diagram  interpretation 

Property  1  ensures  that  the  parameterized  nature  of  the  domain  diagram  is  carried  through  to  the 
mediator  and  target  diagrams.  Property  2  ensures  that  the  body  diagram  is  being  refined  in  a  way  that  is 
compatible  with  the  way  the  formal  parameter  diagram  is  being  refined.  The  refined  formal  parameter 
covers  die  refined  body  in  the  same  way.  Property  3  ensures  that  the  formal  parameter  diagram  is  (in 
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essence)  not  being  refined  at  all  as  all  formal  parameter  moiphisms  are  definitional  extension  morphisms 
(typically  the  identity  morphism).  A  parameterized  diagram  interpretation  ensures  fliat  no  additional 
constraints  are  added  to  die  parameterized  part  (and  no  additional  variability  is  added  to  the  parameterized 
part)  of  the  mediator  and  codomain  diagrams. 

As  an  example,  diis  last  property  ensures  that  die  formal  parameter  One-Sort  in  the  domain 
diagram  will  not  turn  into  the  formal  parameter  Total  Order  in  the  mediator  diagram  as  not  every 
instantiation  of  One-Sort  will  have  a  total  order  operation.  Together  the  three  properties  ensure  that  it  is 
only  the  body  part  diat  is  being  refined  by  the  diagram  interpretation  and  not  the  formal  parameter  part. 
Constrained  parameterized  diagram  interpretation 

Constrained  parameterized  design  information  is  characterized  by  being  associated  with  a 
parameterized  diagram  that  has  been  instantiated  with  some  constraint  diagram.  This  class  of  design 
information  is  represented  by  a  constrained  parameterized  diagram  interpretation  where  the  domain 
diagram  can  be  induced  to  have  a  body  part,  a  formal  parameter  part,  and  a  constraint  part.  (Which  is  an 
instantiation  of  tiie  formal  parameter  part  that  further  restricts  the  variable  part  of  the  body.)  An  example  of 
where  such  a  diagram  interpretation  is  needed  is  refining  a  Sct-of-sonething  to  a  Tics-of-something 
because  the  something  must  have  a  Total-Order  operation  defined  over  it.  The  following  properties  (which 
are  depicted  in  Figure  6-2)  are  required  by  constrained  parameterized  diagram  interpretations: 

1 .  The  entire  diagram  interpretation  must  be  capable  of  being  (re)  partitioned  so  that  flie  domain, 
mediator  and  codomain  diagrams  have  separate  formal  parameter  and  body  parts  and  that  the 
domain  and  mediator  diagrams  have  an  “actual  parameter”  part  in  addition  to  the  formal 
parameter  and  body  parts  that  represents  tiie  “constraint”. 

2.  In  tiie  (re)partition,  the  formal  parameter  diagrams  form  a  diagram  interpretation  and  the  body 
Hiagrams  form  a  diagram  interpretation  and  there  exists  a  (conservative)  diagram 
interpretation  morphism  between  the  two. 

3 .  The  diagram  morphism  from  the  domain  constraint  diagram  to  the  mediator  constraint 
diagram  must  be  a  definitional  extension  morphism  (typically  the  identity  morphism). 

4.  The  diagram  morphism  between  the  mediator  formal  parameter  diagram  and  the  mediator 
constraint  diagram  must  be  a  definitional  extension  morphism  (typically  the  identity 
morphism). 
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Domain  Mediator  Codomain 

Figure  6-2.  Required  properties  of  a  constrained  parameterized  diagram  interpretation 

Properties  1  and  2  have  purposes  similar  to  the  related  required  properties  of  parameterized 
diagram  interpretations.  Properties  3  and  4  ensure  that  the  additional  restrictions  imposed  on  the  formal 
parameter  part,  as  indicated  by  the  constraint  diagram,  are  embedded  in  the  formal  parameter  part  of  the 
mediator  and  target  parameterized  diagrams.  Thus  if  an  actual  parameter  meets  die  requirements  in  the 
constraint  diagrto  (as  well  as  the  requirements  in  the  formal  parameter  diagram)  then  the  refinement  as  a 
whole  is  possible. 


6. 1 2  Examples  of  design  information 

A  parameterized  diagram  interpretation  Bag  List  is  depicted  in  Figure  6-3.  The  Bag=>List 
diagram  interpretation  satisfies  the  required  properties  of  a  parameterized  diagram  interpretation  as  it  can 
be  partitioned  as  depicted  in  Figure  6-4. 


Bag - ►  BagAsList  <-  d  —  List 


Figure  6-3.  Bag  as  List  diagram  interpretation 
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BagOfPairs — ►  BagOfPairs-as-MapToBag  ◄— d—  MapToBag 

Figure  6-5.  BagOfPairs-as-MapToBag  diagram  interpretation 


Figure  6-6.  BagOfPairs-as-MapToBag  parameterized  diagram  interpretation 


Figure  6-7  depicts  a  constrained  parameterized  diagram  interpretation.  The  domain  diagram  of  the 
diagram  interpretation  has  a  Set  specification  for  the  body,  the  One- Sort  specification  as  the  formal 
parameter  and  the  Total-Order  specification  as  the  constraint.  The  meaning  of  the  Set-TO  ^  Tree  diagram 
interpretation  is  fliat  any  Set  that  has  been  instantiated  with  a  sort  that  has  a  total  order  defined  over  it  can 
be  refined  into  a  Tree  where  the  elements  are  stored  in  sorted  order.  The  code  for  Figure  6-7  is  in 
Appendix  F  and  the  partition  that  demonstrates  that  it  is  a  valid  constrained  parameterized  diagram 
interpretation  is  in  Figure  6-8. 


Set-TO - ►  SetAsTree  ◄ — d - Tree 

Figure  6-7.  Set-TotalOrder-as-Tree  diagram  interpretation 


6, 2  Applying  Design  Information 

In  diagram  refinement,  in  order  to  apply  the  design  information  {Spec  interpretations)  the  domain 
(source)  specification  of  the  Spec  interpretation  had  to  match  exactly  a  specification  within  the  requirement 
diagram  being  refined.  In  contrast,  the  domain  (source)  diagram  of  a  diagram  interpretation  need  not 
exactly  match  some  part  of  the  requirement  diagram;  there  must  only  exist  a  diagram  morphism  between 
the  domain  diagram  and  the  requirement  diagram.  Application  of  the  design  information  is  then 
accomplished  via  a  pushout  in  dSpec.  The  design  information  that  is  represented  as  a  diagram 
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interpretation  can  be  applied  to  (the  structure  of)  requirement  specifications  as  well  as  to  other  diagram 
interpretations. 

6.2.1  Repartitioning  the  design  information 

Before  the  design  information  contained  in  a  diagram  interpretation  can  be  applied  to  a 
requirement  diagram,  it  must  be  repartitioned  so  that  the  mediator  and  codomain  diagrams  are  in  the  same 
partition.  Every  diagram  interpretation  is  a  partition  (Definition  3.20)  of  the  following  shape 

of  the  underlying  flattened  (Definition  3.18)  Spec  diagram.  As  such,  every  diagram 
interpretation  can  also  be  partitioned  to  have  the  following  shape  ®  >,  where  the  definitional 

extension  morphism  (and  its  dom  and  cod  diagram  objects)  have  been  partitioned  to  be  in  a  single  diagram. 
Thus  the  diagram  interpretations  in  Figure  4-14,  Figure  6-3,  Figure  6-5,  and  Figure  6-7  can  be  partitioned 
into  the  dSpec  diagrams  in  Figure  6-9. 

The  diagram  on  the  left  in  each  of  the  repartitioned  diagram  interpretations  in  Figure  6-9 
represents  iSOit  preconditions  for  applying  the  design  information.  These  preconditions  must  be  present  in 
the  requirement  specification  before  the  design  information  can  be  applied.  The  diagram  on  the  right  in 
each  case  represents  the  design  information  that  is  to  be  applied. 

6.2.2  Using  a  dSpec  pushout  to  apply  design  information 

In  order  to  apply  the  design  information,  one  first  forms  a  diagram  moiphism  fi*om  the  required 
preconditions  diagram  to  the  requirement  diagram.  This  establishes  that  die  preconditions  for  using  the 
design  information  exist  in  the  requirement  diagram.  One  then  takes  the  pushout  of  the  resultant  dSpec 
diagram,  RequirementDiagram<— Precondition— >DesignInfo,  as  depicted  in  Figure  6-10.  In  that  figure,  a 
diagram  morphism  is  formed  between  the  preconditions  for  the  design  information  and  the  requirement 
specification  version  n.  Having  established  the  relationship,  the  dSpec  pushout  (Definition  3.27)  of  the 
resulting  dSpec  diagram  is  taken,  which  merges  Ihe  design  information  and  the  requirement  specification  n 
to  form  a  new  requirement  specification  version  n+1. 
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Figure  6-10.  Applying  design  information  to  a  requirement  specification 


As  an  example  application  of  diagram  information,  in  Figme  6-1 1  fhe  Set-TO  to  Tree 
interpretation  has  been  applied  to  the  simple  requirement  specification  Set  of  Nat.  Note  that  the 
repartitioned  diagram  interpretation  Set-TO  to  Tree  has  been  internally  “flipped”  from  how  it  was 
represented  in  Figure  6-9  in  order  to  have  the  arrows  making  up  the  diagram  morphisms  line  up  better. 
Also,  some  of  the  Spec  arrows  making  up  the  diagram  morphisms  are  labeled  with  id  for  the  identity 
morphism  so  that  the  specifications  in  the  resulting  colimit  object  can  more  easily  be  related  to  the 
specifications  in  the  diagram  objects  from  which  the  colimit  object  was  formed.  The  pushout  object 
diagram  that  is  the  result  of  applying  design  information  is  “version  2”  of  die  requirement  specification. 
The  requirement  specification  is  still  a  Set-of-Nat  but  the  design  choice  that  the  Set  specification  is  to  be 
implemented  by  a  Tree  specification  has  been  integrated  into  the  next  version  of  die  requirement 
specification.  The  application  of  a  design  choice  results  in  a  more  detailed  requirement  specification  as  the 
new  design  information  is  now  part  of  the  requirements  as  well.  In  this  case,  the  Tree  -(!—»■  SetAsTree 
definitional  extension  morphism  indicates  how  a  Tree  ADT  can  be  extended  to  implement  a  Set  ADT. 

Thus  one  no  longer  has  to  worry  about  implementing  a  Set,  one  ordy  has  to  implement  a  Tree.  Any  further 
refinements  would  be  applied  to  the  Tree  specification,  which  has  the  Total-Order  specification  as  its 
formal  parameter. 
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Figure  6-11.  Example  application  of  design  information 


Note  the  diagram  morphism  between  the  two  versions  of  the  requirement  diagrams  in  Figure  6-11 
(and  the  abstraction  in  Figure  6-10).  Each  successive  design  decision  is  applied  to  the  results  of  the 
previous  design  decision,  as  the  application  of  design  information  literally  produces  a  new  requirement 
diagram.  To  paraphrase  [SB82],  requirements  and  design  are  inevitably  intertwined.  With  each  application 
of  design  information,  the  specifications  in  the  requirements  diagram  become  more  detailed  and  more  like 
design  specifications.  The  sequence  of  diagram  morphisms  between  the  versions  of  the  requirement 
diagrams  form  a  chain  enabling  the  original  requirements  to  be  related  directly  to  the  final  design. 

Figure  6-12  depicts  a  sequence  of  design  decisions  being  applied  consecutively  to  a  requirement 
diagram,  which  starts  out  as  a  Set  of  Set  of  Flags.  The  first  design  choice  is  to  represent  the  outer  Set  as  a 
Bag.  The  second  design  choice  is  to  represent  the  Bag  as  a  List.  (The  “Bag”  requirement  in  Req  V2  is 
“new”  based  on  the  last  design  decision.)  The  third  design  decision  is  to  represent  the  inner  Set  as  a  List. 
Rather  than  using  the  individual  design  decisions  of  Set  =>Bag  and  Bag  =>  List,  a  direct  design  decision 
Set  =>  List  is  being  applied.  Section  6.2.3  addresses  how  design  information  composes  so  that  Set  i=>  List 
can  be  formed  from  the  existing  design  decisions  Set  =>  Bag  and  Bag  =>  List.  In  the  fourth  design 
decision,  the  specification  Flag  has  been  refined  to  specification  Nat. 
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Note  that  in  the  diagram  morphism  Req  V2— >’Req  V3  in  Figure  6-12  that  the  SetAsBag  specification 
has  been  changed  to  the  SetAsBag  AsList  specification.  This  is  because  the  addition  of  the  Bag=>List 
design  information  “rippled”  through  to  the  SetAsBag  specification,  which  is  what  was  wanted.  When  a 
specification  in  a  diagram  is  changed  by  adding  additional  design  mformation  to  it,  any  specifications 
“downstream”  of  it  will  also  be  affected. 

In  some  cases  design  information  must  be  applied  in  a  specific  order.  In  this  case  it  did  not  matter 
whether  the  inner  Set  or  outer  Set  was  refined  first.  However,  the  choice  to  represent  the  outer  Set  as  a  Bag 
had  to  proceed  the  choice  to  represent  the  Bag  as  a  List.  This  demonstrates  how  earlier  design  decisions 
can  influence  and  make  available  additional  design  decisions. 

An  alternate  design  decision  in  Figure  6-12  could  have  been  to  represent  the  inner  Set  as  a  Tree 
using  the  Set-TO  to  Tree  design  choice.  Initially  this  design  choice  is  not  possible  as  there  is  no  total  order 
operation  defined  in  the  Flag  specification.  However,  once  the  design  decision  is  made  to  implement  the 
Flag  specification  by  the  Nat  specification,  the  Flag  sort  will  have  a  total  order  operation  defined  over  it 
that  is  derived  from  its  implementation  as  a  Nat.  Thus  if  the  Flag  as  Nat  design  decision  is  made  earlier, 
this  opens  up  the  possibihty  of  storing  the  set  of  Flags  as  a  sorted  Tree  that  makes  it  quicker  to  access  the 
elements.  (Although  for  this  simple  case  the  Flag  sort  only  has  three  values  making  this  a  “bad”  design 
choice;  a  bit  vector  may  be  better). 

Note  that  the  application  of  the  design  choice  Flag=>Nat  is  easily  accomplished  without  causing 
the  problems  experienced  by  the  diagram  refinement  approach. 

6.2.3  Applying  design  information  to  design  information 

Rather  than  apply  all  design  information  to  a  requirement  specification,  it  ought  to  be  possible  to 
apply  design  information  to  itself.  This  capability  enables  larger  “chunks”  of  design  information  to  be 
applied  as  a  unit.  As  the  accompanying  text  for  Figure  6-12  implied,  rather  than  having  to  apply  a  Set-to- 
Bag  refinement  and  then  a  Bag-to-List  refinement,  it  should  be  possible  to  join  those  two  design  decisions 
into  a  single  one  so  that  a  Set-to-List  refinement  can  be  applied.  While  Definition  4.8  ensures  that  diagram 
interpretations  compose,  it  is  not  necessarily  the  case  that  the  properties  associated  with  the  different 
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classificstions  of  diagram  interpretations  compose.  This  section  develops  the  underlying  theory  of 
composing  design  information  and  provides  several  examples  of  composing  design  information. 

Simple  diagram  interpretation  composition 

The  class  of  simple  design  information  conq)Oses  using  normal  diagram  interpretation 
composition  (Definition  4.8).  Given  fliat  A=>B  and  B=>C  are  instances  of  simple  design  information,  then 
A=>C  is  also,  as  “variability”  cannot  be  introduced  during  the  composition. 

Parameterized  diagram  interpretation  composition 

The  class  of  parameterized  design  information  composes  as  depicted  in  Figure  6-13.  At  the  top  of 
tiiat  figure  are  two  parameterized  diagram  interpretations  with  a  common  domain/codomain.  In  the  middle, 
two  separate  pushouts  are  taken  to  form  the  formal  parameter  and  body  of  the  new  mediator  of  die  design 
information.  The  arrow  between  the  new  formal  parameter  and  the  body  is  die  imiversal  arrow  between  a 
colimit  object  and  any  other  cocone  object  of  a  given  diagram.  At  the  bottom  of  Figure  6-13,  anow 
composition  is  used  to  connect  die  new  mediator  with  the  domain  and  codomain  diagrams  creating  a  new 
parameterized  diagram  interpretation. 

The  anow  that  connects  the  New  Mediator  formal  parameter  diagram  to  the  New  Mediator  body 
diagram  in  Figure  6-13  will  always  be  a  conservative  extension  given  that  it  is  two  parameterized  diagram 
interpretations  that  are  being  conqiosed.  Notice  that  the  commuting  square  connecting  the  right  Mediator 
diagram  to  the  New  Mediator  diagram  will  necessarily  look  like  the  commuting  square  on  the  left  in  Figure 
6-14.  (Where  the  property  of  the  diagram  morphism  from  the  formal  parameter  to  the  body  is  not  known, 
but  the  other  diagram  morphism  properties  must  be  as  depicted.)  In  the  middle  diagram  in  Figure  6-14  a 
pushout  object  has  been  formed  and  the  arrows  to  it  will  be  definitional  and  conservative  extension 
morphisms,  as  those  properties  reflect  across  pushout  squares  (Proposition  4.3).  There  must  also  exist  a 
universal  arrow  as  indicated  whose  properties  are  also  not  yet  known.  On  the  right  in  Figure  6-14  the 
universal  arrow  has  been  determined  to  be  a  definitional  extension  morphism,  as  the  two  definitional 
extension  morphisms  compose  to  form  a  definitional  extension  morphism.  Finally,  the  unknown  New 
Mediator  diagram  morphism  is  determined  to  be  a  conservative  extension  morphism  based  on  it  being 
equivalent  to  die  composition  of  a  conservative  extension  and  definitional  extension  morphism.  Thus 
normal  diagram  composition  is  all  that  is  needed  to  compose  two  parameterized  diagram  interpretations. 
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Figure  6-13.  Composing  parameterized  dinterpretations 


New  Mediator 


Figure  6-14.  Formal  parameter  ->  Body  arrow  of  the  New  Mediator  is  a  conservative  extension 
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An  example  composition  of  parameterized  diagram  interpretations  is  depicted  in  Figure  6-15. 
That  figure  depicts  the  results  of  composing  the  Set=>Bag  and  Bag=>List  interpretations. 

Constrained  parameterized  diagram  interpretation  composition 

Both  simple  and  parameterized  diagram  inteipretations  compose  with  the  normal  diagram 
interpretation  mechanism  from  Definition  4.8.  This  approach  only  partially  works  with  constrained 
parameterized  diagram  interpretations.  When  a  constrained  parameterized  diagram  Interpretation  is  being 
applied  to  a  requirement  specification  (diagram),  the  constraint  and  the  domain  parameterized  diagram  are 
treated  as  a  single  unit  (as  are  the  mediator  and  codomain  parameterized  diagrams  and  the  mediator 
constraint),  see  Figure  6-11.  This  is  possible  because  in  order  for  the  design  information  to  be  applied 
correctly  the  properties  in  the  constraint  must  be  present  in  the  requirement  specification.  That  is,  the 
parameterized  diagram  must  have  been  instantiated  in  the  requirement  specification  and  therefore  it  is 
possible  to  determine  whether  or  not  the  given  requirement  instantiation  satisfies  the  properties  in  the 
constraint.  However,  when  composing  constrained  parameterized  diagram  interpretations  no  instantiation 
has  taken  place  and  therefore  the  constraining  diagrams  must  be  treated  separately  from  the  domain, 
mediator  and  codomain  parameterized  diagrams.  Constrained  parameterized  diagrams  can  also  be 
composed  on  the  left  (Figure  6-16)  or  on  the  right  (Figure  6-17)  with  “normal”  parameterized  diagrams. 
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Figure  6-16.  Composition  with  a  (left)  constrained  parameterized  dinterpretation 


When  composing  a  constrained  parameterized  diagram  interpretation  on  the  left  wifli  a 
parameterized  diagram  interpretation,  as  depicted  in  the  top  diagram  in  Figure  6-16,  the  constraint  is  easily 
propagated  to  the  composed  diagram  interpretation.  The  middle  diagram  in  Figure  6-16  depicts  how  a 
pushout  factors  the  constraint  through  to  the  new  mediator.  The  bottom  diagram  in  Figure  6-16  depicts 
how  morphism  composition  conqrletes  the  new  composed  constrained  parameterized  diagram 
interpretation. 

In  Figure  6-16,  where  die  constraining  diagram  is  on  the  left  parameterized  diagram  interpretation, 
the  constraint  is  propagated  via  a  sinqile  pushout.  WTien  composing  a  constrained  parameterized  diagram 
interpretation  on  the  right  with  a  parameterized  diagram  interpretation,  as  depicted  in  the  top  diagram  in 
Figure  6-17,  die  constraint  can  also  be  propagated.  Note  that  in  the  top  diagram  in  Figure  6-17  the  two 
(domain/codomain)  parameterized  diagrams  were  joined  based  on  their  common  formal  parameters  and 
bodies  and  diat  the  constraint  placed  on  the  right  domain  parameterized  diagram  is  now  constraining  the 
combined  domain/codomain  parameterized  diagram.  The  constraint  will  not  occur  in  die  left  parameterized 
diagram  interpretation,  yet  in  order  to  compose  the  two  it  must  be  propagated  to  the  domain  parameterized 
diagram  of  the  left  parameterized  diagram  interpretation. 

The  top  diagram  in  Figure  6-17  also  depicts  how  a  pushout  and  a  composition  of  morphisms 
factors  the  constraint  from  the  dorriain/codomain  parameterized  diagram  through  to  the  domain  of  the  first 
diagram  interpretation.  In  the  second  diagram  in  Figure  6-17  a  pushout  is  used  to  factor  the  constraint 
through  to  the  new  mediator.  In  the  third  diagram  in  Figure  6-17  an  additional  pushout  is  used  to  extend 
the  new  mediator  constraint  (if  needed)  and  to  ensure  that  it  has  a  definitional  extension  morphism  to  it 
from  the  new  domain  constraint  that  was  constracted  in  the  top  diagram.  The  bottom  diagram  in  Figure 
6-17  depicts  how  morphism  composition  completes  the  newly  composed  constrained  parameterized 
diagram  interpretation.  Thus  while  the  formal  parameters  and  bodies  of  the  corrqiosed  diagram 
interpretations  are  always  computed  via  the  normal  diagram  interpretation  composition,  any  constraining 
diagrams  must  be  handled  separately  as  depicted  in  Figure  6-16  and  Figure  6-17. 
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Figure  6-17.  Composition  with  a  (right)  constrained  parameterized  dlnterpretation 
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Composing  two  constrained  parameterized  diagram  interpretations  is  also  possible.  In  Figure 
6-18,  a  pushout  is  used  to  factor  the  right  constraint  “over”  the  left  constraint.  Then  the  morphism  from  tiie 
left  diagram  interpretation’s  domain  formal  parameter  to  the  new  constraint  is  constructed  via  the 
composition  of  dnree  morphisms.  The  new  constraint  on  the  left  domain  formal  parameter  in  Figure  6-18 
necessarily  contains  the  old  constraint  on  the  left  domain  formal  parameter  as  well  as  the  constraint  on  the 
right  domain. 

Compare  the  diagram  in  Figure  6-18  with  the  diagram  at  the  top  of  Figure  6-17  to  see  how  the 
right  constraint  was  placed  over  the  left  constraint.  The  rest  of  the  sequence  in  Figure  6-17  can  now  be 
used  to  complete  the  constraction  of  the  constrained  parameterized  diagram  interpretation  in  Figure  6-18. 


Figure  6-18.  Composition  with  two  constrained  parameterized  dinterpretations 


Codomain 


An  example  of  parameterized  diagram  interpretation  composition  that  involves  constraints  is 
depicted  in  Figure  6-19.  Normal  diagram  interpretation  composition  is  used  to  construct  the  new  mediator. 
The  constraint  is  propagated  to  the  new  parameterized  diagram  interpretation  via  a  succession  of  colmuts 
that  involve  the  formal  parameter  diagrams  as  described  earlier. 

In  smnmary,  all  fliree  classes  of  design  information  compose  by  normal  diagram  interpretation 
with  the  exception  of  the  constraint  information.  That  information  can  be  composed  by  operating  strictly 
over  the  constraint  and  formal  parameter  sub-diagrams. 
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6. 3  Simplifying  the  Structure  of  Design  Information 


The  two  previous  sections  have  described  the  dieory  of  representing,  composing  and  applying 
design  information  using  diagram  interpretations  (and  repartitioned  diagram  interpretations)  and  presented 
several  examples.  As  can  be  seen,  the  number  of  objects  and  arrows  in  the  diagrams  for  even  these  small 
examples  can  be  a  bit  daunting.  There  are  a  few  short  cuts  that  one  can  take  in  representing,  composing 
and  applying  design  information  that  make  it  more  palatable  than  has  been  previously  depicted. 

Design  information  must  only  be  proven  correct  once  prior  to  being  stored  in  a  design  library  and 
made  available  for  reuse,  and  it  need  not  be  developed  and  represented  in  diagram  interpretation  form.  In 
certain  contexts  the  design  information  can  be  represented  in  a  simpler  fashion  than  has  been  previously 
presented. 


6.3.1  Motivating  exanqile 

As  a  motivating  example.  Figure  6-20  depicts  the  effects  of  a  pair  of  structure-reducing  operations 
that  start  with  the  final  requirement  diagram  fi-om  Figure  6-12.  In  the  transition  from  Req  Vs  to  Req  Vs,  the 
BagAsList  specification  is  removed  because  it  is  the  intermediate  specification  between  a  pair  of 
definitional  extension  moiphisms.  (The  pair  of  d-morphisms  List  — d— >  BagAsList  — d— >  SetAsBagAsList  is 
reduced  to  the  definitional  extension  morphism  List  — d— >  SetAsBagAsList,  as  the  intermediate  definitional 
extension  does  not  really  add  any  information  to  the  requirement  diagram.  It  has  served  its  purpose  so  to 
speak.)  This  reduction  induces  an  obvious  diagram  morphism  from  diagram  Req  Vs  to  diagram  Req  Ve.  As 
no  new  stmcture  or  design  ioformation  has  been  added,  it  essentially  is  a  no-op. 

In  the  transition  fi-om  Req  Ve  to  Req  y^  all  nodes  in  the  diagram  with  an  identity  morphism 
between  them  are  folded  together  (Definition  3.23).  Thus  the  multiple  One-Sort  specifications  are 
removed.  As  the  fold  operation  induces  a  diagram  morphism  between  the  diagrams,  there  is  an  obvious 
diagram  morphism  fiom  diagram  Req  vg  to  diagram  Req  V7.  The  requirement  specification  Req  y^  is  a 
valid  refinement  of  die  requirement  specification  Req  V5.  Req  y^  indicates  that  a  Set  of  Set  of  Flags  is  to  be 
implemented  with  the  following  smaller  refinements:  The  outer  Set  is  to  be  implemented  as  a  List,  the  inner 
Set  is  to  be  implemented  as  a  List,  and  Flags  are  to  be  implemented  as  a  subsort  of  the  natural  numbers. 
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The  final  version  of  the  requirement  diagram  in  Figure  6-20  is  easier  to  comprehend  and  work 
with  than  the  requirement  diagram  prior  to  the  structure  reductions.  However,  instead  of  reducing  the 
requirement  specification  structure  after  design  information  is  applied,  it  may  be  better  if  the  design 
information  structure  itself  is  reduced.  Reducing  the  structure  of  the  design  information  means  that  it  can 
be  developed  and  applied  with  less  work.  Even  when  the  design  information  is  reduced,  however,  cases 
will  still  arise  that  introduce  extraneous  structure  in  the  refined  requirement  specification. 


Figure  6-20.  Reducing  unneeded  structure  in  the  requirement  diagram 

6.3,2  Reducing  design  information  structure 

The  classes  of  design  information  presented  in  Section  6.1.1  indicate  the  necessary  properties  for  a 
simple,  parameterized,  or  constrained  parameterized  diagram  to  be  refined  safely  so  that  the  refinement  can 
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be  represented  as  design  information.  Section  6.2  described  how  that  design  information  can  be  applied 
and  composed.  Assuming  that  a  diagram  interpretation  meets  the  requirements  of  one  of  the  classes  of 
design  information  in  Section  6.1.1,  it  can  then  be  reduced  in  structure  so  that  its  application  and 
composition  can  be  accomplished  in  an  easier  fashion. 

As  an  example,  in  Figure  6-21  and  Figure  6-22  the  four  repartitioned  diagram  interpretations  from 
Figure  6-9  have  been  reduced  in  structure.  Specifically,  in  each  case  the  formal  parameters  (in  the  single 
repartitioned  design  information  part  of  the  diagram)  have  had  identity  morphisms  between  them  folded 
together.  In  die  case  of  the  BagofPairs  diagram  interpretation,  additional  nodes  with  identity  morphisms 
between  them  were  combined  in  addition  to  the  formal  parameters,  as  tiiey  were  introduced  to  insure  that 
all  of  the  formal  criteria  for  a  parameterized  diagram  refinement  were  present.  Even  with  all  of  the 
reduction  in  structure  there  still  exists  a  diagram  morphism  to  it  from  the  preconditions  part  of  the  design 
information. 


Bag - ►  BagAsList+ 


Figure  6-21.  Reduced  and  repartitioned  dinterpretations  as  design  information  I 
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Note,  however,  that  in  the  Set  to  Tree  diagram  interpretation  at  the  bottom  of  Figure  6-22,  the 
identity  morphism  to  the  constraint  (Total-Order)  of  the  design  information  remains  as  a  separate  node. 
Maintaining  the  constraint  separately  is  critical  in  terms  of  applying  the  design  information,  as  without  that 
separation  too  much  of  the  structure  of  requirement  specification  will  be  combined  when  the  design 
information  is  applied. 


BagOfPairs - - ►  BagOfPairs-as-MapToBag+ 


Ony-i^rt''\  Total -Order 


Set-TO - ►  SetAsTree+ 


Figure  6-22.  Reduced  and  repartitioned  dinterpretations  as  design  information  11 

An  example  of  the  application  of  reduced-structure  design  information  is  depicted  in  Figure  6-23; 
compare  it  to  the  non-reduced  example  depicted  in  Figure  6-11.  Note  how  the  pushout  diagram,  Req  V2, 
does  not  contain  an  extra  One-Sort  formal  parameter  specification  as  it  did  the  previous  version.  The 
application  of  the  reduced-structure  design  information  avoided  placing  unneeded  structure  in  the  pushout 
requirement  diagram. 
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\  SetAsTree  Nat  / 


Reqv2 

Figure  6-23.  Example  application  of  design  information  with  reduced  structure 

Now  compare  Figure  6-23  with  Figure  6-24,  where  the  constraint  specification  (Total-Order)  was 
combined  with  the  formal  parameter  specification.  Note  how  the  instantiated  specification  Nat  becomes 
the  “formal  parameter”  in  the  pushout  diagram  object.  Too  much  of  the  stracture  in  the  requirement 
specification  has  been  collapsed.  Thus  when  reducing  the  stmcture  of  design  information  it  is  acceptable  to 
combine  the  formal  parameters  but  the  constraint  must  be  maintained  as  a  separate  entity. 
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/  One -Sort 


\  SetAsTree+Nat  / 


Reqv2 

Figure  6-24.  Example  application  of  design  information  where  structure  is  reduced  too  much 

In  some  cases  the  composition  of  reduced-structure  design  information  becomes  simpler.  In  fact  it 
becomes  no  different  than  applying  design  information  to  a  requirement  specification,  as  Figme  6-25 
depicts.  In  Figure  6-25  a  diagram  morphism  is  formed  between  the  “preconditions”  of  the  BagAsList 
design  choice  to  the  design  information  in  the  SetAsBag  design  choice.  Once  the  dSpec  pushout  of  that 
diagram  is  taken,  the  resulting  diagram,  SetAsBagAsList+,  is  connected  with  the  preconditions  of  the 
SetAsBag  design  choice  via  morphism  composition.  As  this  resulting  composition  still  has  unneeded 
structure,  it  can  be  reduced  still  further  as  depicted  in  Figure  6-26  where  the  unneeded  intermediate 
definitional  extension  has  been  eliminated.  Thus  reduced-structure  design  information  can  still  be 
composed  despite  it  no  longer  having  the  form  of  a  diagram  interpretation. 
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Figure  6-25.  Composition  of  reduced-structure  design  information 


Set - ►  SetAsBagAsListH- 


Figure  6-26.  Unneeded  structure  in  a  requirement  diagram  is  eliminated 

As  a  final  example  of  composing  design  information,  Figure  6-27  depicts  composing  (reduced- 
structure)  design  information  via  pushout  where  the  constraint  is  handled  outside  of  the  pushout 
mechanism.  Once  the  structure  of  a  constrained  parameterized  diagram  interpretation  has  been  reduced, 
constraints  cannot  be  handled  in  as  mechanical  a  fashion  as  described  in  Section  6.2.3.  Composition  of 
constrained  parameterized  diagram  interpretations  is  still  possible,  though,  as  depicted  in  Figure  6-27 . 
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(5. 4  Example  Application  of  Design  Information 

This  section  refines  a  portion  of  that  requirement  diagram  into  a  more  concrete  data 
representation.  Specifically,  the  Bag  of  input  arcs  sub-diagram  fi:om  the  Petri  Net  requirement  diagram  is 
refined  into  a  more  concrete  and  implementable  data  structure  in  Figure  6-28  and  Figure  6-29. 

The  first  design  choice  in  Figure  6-28  is  to  represent  the  Place  and  Transition  sorts  as  natural 
numbers.  As  the  Place  and  Transition  specifications  are  isomorphic  to  the  One-Sort  specification,  this 
addition  of  design  information  is  fairly  trivial.  Note  that  the  refinement  of  both  Place  and  Transition  is 
done  in  one  large  colimit,  demonstrating  that  multiple,  non-conflicting  design  choices  can  be  accomplished 
at  the  same  time. 

The  second  design  decision  is  to  implement  the  Bag  of  input  arcs  (pairs  of  places  and  transitions) 
as  a  Map  fi:om  a  place  to  a  Bag  of  transitions.  Note  that  this  design  choice  has  appreciably  changed  the 
structure  of  the  requirement  diagram.  Such  a  refinement  is  not  possible  when  using  the  diagram  refinement 
approach.  The  Bag  specification  in  the  diagram  BagOfInputArcs2  is  completely  unrelated  to  the  Bag 
specification  in  BagOfInputArcss.  The  original  Bag  specification  is  only  an  emergent  property  (via  a 
definitional  extension)  of  the  new  data  stracture,  which  is  a  Map  to  a  Bag,  i.e.  the  BagOfPairs-as- 
MapToBag  specification.  The  refinement  continues  in  Figure  6-29. 

The  third  design  decision  refines  a  Map  to  an  Array  as  the  constraint  on  the  codomain  parameter 
specification  of  the  map  (being  a  discrete  linear  order,  Di-LO,  Figure  C-3)  has  been  met  by  the  PlaceAsNat 
actual  parameter  in  the  requirement  diagram.  In  the  new  requirement  diagram,  the  pushout  diagram 
BagOfOnputArcs4,  note  that  the  specification  BagOfPairs-as-MapAsArrayToBag  has  also  been  effected  as 
the  design  information  MapAsArray  has  rippled  through  to  it,  which  is  what  was  wanted. 

The  fourth  design  decision  refines  a  Bag  to  a  Tree  as  the  constraint  on  the  formal  parameter  of  Bag 
(being  a  total  order)  has  been  met  by  the  TransitionAsNat  actual  parameter  in  the  requirement  diagram. 
Again,  in  the  new  requirement  diagram  the  design  information  has  rippled  through  to  the 
BagOfPairs-as-MapAsArrayToBagAsTree  specification;  this  ripple  through  of  the  design  information  is 
exactly  what  is  wanted. 
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ne-Sort 


Figure  6-28.  Petri  Net  data  structure  example  I 
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Because  the  TransitionAsNat  sort  is  also  a  discrete  linear  order,  an  alternate  fourth  design  decision 
could  have  been  to  refine  the  Bag  of  Transitions  into  an  Array  of  occurrences.  In  this  design  choice  the 
array  would  be  indexed  by  the  TransitionAsNat  value  and  the  value  at  that  array  position  would  be  the 
count  of  the  number  of  occurrences  in  the  Bag  of  that  particular  index  value.  The  choice  as  to  which  fourth 
design  decision  to  make  should  be  subject  to  the  designer’s  knowledge  of  the  problem.  Since  for  any  given 
Petri  Net  the  number  of  transitions  in  any  particular  Bag  is  will  in  all  probability  be  low,  the  original  design 
choice  is  probably  best  as  it  will  conserve  space  under  those  conditions.  If  the  designer  had  advance 
knowledge  that  fully  interconnected  Petri  Nets  (with  multiple  arcs  between  any  given  places  and 
transitions)  were  to  be  modeled,  then  the  alternate  fotirth  design  decision  might  be  better,  as  it  would 
conserve  space  and  be  faster  to  access  under  those  conditions. 

Assuming  that  one  already  has  arrays  and  trees  implemented  in  the  target  programming  language, 
this  collection  of  design  decisions  is  complete.  (Except  for  ensuring  that  all  code  generation  requirements 
have  been  met,  see  Section  C.5.)  The  abstract  requirement  a  bag  of  input  arcs  (a  bag  of  <place,  transition> 
pairs)  has,  through  a  series  of  design  decisions  and  associated  additions  of  design  information,  been 
transformed  into  an  array  of  trees.  Even  though  the  entire  Petri  Net  diagram  was  not  depicted  during  the 
refinements  in  Figure  6-28  and  Figure  6-29,  the  four  design  decisions  in  those  figures  are,  for  the  most  part, 
independent  of  the  rest  of  the  Petri  Net  diagram. 

This  final  example  demonstrates  that  the  technique  of  storing  design  information  as  (repartitioned 
and  structure-reduced)  diagram  interpretations  solves  the  problems  and  misapplications  of  Spec 
interpretation  and  diagram  refinement  expounded  upon  in  Section  2.5.  It  involves  restructuring  design 
information,  parameterized  design  information  and  constrained  parameterized  design  information. 

Although  Figure  6-28  and  Figure  6-29  did  not  depict  it,  the  requirement  diagram  being  refined  is  actually 
just  a  sub-diagram  of  the  Petri  Net  example  (Section  5.3.6  and  Appendix  D).  The  sequence  of  refinements 
could  have  been  made  to  the  much  larger  Petri  Net  diagram  without  encountering  any  of  the  problems 
associated  with  diagram  refinement. 
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6,5  Contributions  and  Future  Work 


Contributions  of  this  chapter  include  the  use  of  diagram  interpretations  as  a  mechanism  for 
representing  structured  design  information,  specifically  parameterized  diagram  interpretations  and 
constrained  parameterized  diagram  interpretations.  The  definitions  of  these  specialized  diagram 
interpretations  enable  parameterized  design  information  to  be  represented  and  applied  in  a  correct  manner. 
For  parameterization  diagrams  in  general,  they  enable  the  body  part  to  be  refined  independently  of  its 
formal  parameter  part,  as  guaranteed  by  the  conservative  diagram  interpretation  morphism  between  the 
formal  parameter  parts  and  the  body  parts  in  the  (re)partitioned  diagram  inteipretation.  For  constraints  on 
the  parameter  part  they  enable  the  application  of  that  design  information  to  ensure  that  the  actual  parameter 
in  the  requirement  diagram  satisfies  those  constraints  before  the  design  information  can  be  applied. 
Constrained  parameterized  diagram  interpretations  are  a  powerful  tool,  as  they  enable  the  refinement  of  a 
body  part  to  take  advantage  of  the  properties  in  a  particular  instantiation  by  guaranteeing  diat  those 
properties  exist.  The  different  forms  of  design  information  are  shown  to  compose,  which  means  that  larger 
chunks  of  design  information  can  be  built  up  from  smaller  pieces  and  applied  as  a  unit  instead  of 
piecemeal. 

A  second  contribution  of  the  chapter  is  the  use  of  pushout  diagrams  in  dSpec  to  apply  design 
information,  i.e.  (re)partitioned  diagram  interpretations,  to  requirement  specifications.  Using  a  pushout  as 
the  means  of  applying  design  information  automatically  induces  the  needed  diagram  morphism  between 
successive  versions  of  the  requirement  specification  and  ensures  that  any  preconditions  of  the  design 
information  are  satisfied  before  the  design  information  can  be  applied. 

A  third  contribution  of  the  chapter  is  the  capability  of  reducing  the  structure  of  the  diagram 
interpretation  design  information  so  that  it  can  be  more  easily  generated  and  applied.  While  the  full 
structure  of  parameterized  diagram  interpretations  and  constrained  parameterized  interpretations  may  be 
needed  to  ensure  that  one  is  correctly  refining  the  body  independent  of  the  formal  parameter,  that  full 
structure  is  not  needed  to  represent  and  apply  the  design  information,  as  was  demonstrated  in  Section  6.3. 
(The  full  structure  is  needed  to  verify  the  design  information  is  correct  but  that  structure  is  not  needed  to 
apply  the  design  information  correctly.) 
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Future  work  involves  investigating  other  classes  of  design  information  that  can  be  represented  as  a 
diagram  and  applied  via  pushout.  An  example  is  the  case  where  the  “precondition”  structure  of  the  design 
information  involves  component  specifications  and  a  property  defined  over  an  aggregate  of  the 
components.  The  preconditions  of  the  design  information  cannot  be  satisfied  by  the  components  alone  as  it 
is  only  in  the  aggregate  that  one  can  determine  if  certain  properties  hold.  A  simple  example  of  such  a 
problem  involves  the  school  domain,  where  there  exists  a  set  of  students  and  a  set  of  instructors  and  a 
relation  over  their  aggregate  that  ensures  that  each  student  has  an  advisor  relation  with  one  of  the 
instructors  in  the  set  of  instructors.  If  such  a  condition  is  stated  in  the  aggregate,  then  by  applying  one  of 
these  design  decisions  the  relationship  can  be  embedded  in  both  the  student  and  teacher  sorts.  The  teacher 
sort  can  be  extended  to  contain  a  set  of  students  for  which  he  or  she  is  the  advisor  and  the  student  sort  can 
be  extended  to  contain  the  instructor  that  is  his  or  her  advisor.  An  alternate  design  decision  would  be  to 
contain  that  information  in  either  the  teacher  sort  or  the  student  sort  but  not  both.  Yet  another  design 
decision  would  be  to  create  a  new  sort  independent  of  the  teachers  and  students  that  contains  the 
relationship. 
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7  Conclusions 

The  purpose  of  this  investigation  was  to  develop  methods  foi  constnictiiig  and  retlning  structured 
algebraic  requirement  specifications,  and  more  specifically  ihc  representation  and  application  of  design 
information.  The  current  method  of  constructing  requirement  diagrams  (diagram  construction  by  listing 
nodes  and  arcs)  does  not  scale  well  for  large  aggregate  objecis.  Another  aggregate  specification 
develtipment  method,  paranieterized  &pecifioatioiifi,  results  in  a  specific ation  rather  thisn  a  structurad 
diagram  Currem  representations  of  design  information  (specifications,  morp^sms,  and  interpretaiions) 
and  methods  for  design  information  application  (diagram  refinement)  are  not  able  to  represent  design 
informahon  adequately  so  that  it  can  be  applied  correctly. 

As  part  of  the  dUsertation  research,  a  category  of  diagrams  and  diagram  morpbtsms  was 
developed  and  applied  to  algebraic  specifications  and  morpliisms  that  enables  the  structure  of  requirement 
specifications  and  design  infoiraaiiou  to  be  dealt  with  explicitly.  A  theory  of  diagram  parameterization  and 
instantiation  was  developed  that  enables  large  requirement  specifications  to  be  built  using  a  parameter- 
passing  analogy  rathet  than  a  diagram  building  analogy.  A  theory  of  diagram  interpretations  wai 
developed  that  enables  structured  design  information  to  be  correctly  represenred  and  applied,  including  tlic 
refinement  of  parameterized  diagrams,  restructuring  refinements,  and  establishing  precondirions  for  the 
application  of  the  design  information.  Together  these  innovations  solve  the  problem  that  current  methods 
have  with  constructing  requirement  specifications  and  correctly  representing  and  applying  design 

information. 

The  specific  couiributions  of  this  research  arc  described  in  Section  7. 1 ,  followed  by  possible  future 

work  in  Section  7.2. 

7. 1  Contributions 

The  fust  contribution  is  the  formalization  of  a  category'  of  diagrams,  dX,  in  Chapter  3 .  While 
diagrams  art  ubiquitous  in  categor>'  theory  and  the  notion  of  a  diagram  as  a  functor  from  a  shape  category 
to  4  target  category  is  also  common  [AHS^],  this  19  the  fust  time  that  tiie  diagrams  themselves  have  been 
treated  as  objects  in  their  own  category.  The  arrows  of  a  diagram  category,  diagram  morphisms,  ensure 
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that  both  the  content  and  the  structure  of  a  source  diagram  are  preserved  in  a  target  diagram.  The 
formalization  of  the  category  rfX  is  generic  in  that  it  applies  to  all  other  categories,  X.  This  generic 
formalization  makes  this  contribution  more  applicable  than  if  the  category  of  diagrams  had  been  developed 
in  the  framework  of  a  concrete  category. 

The  second  contribution  is  the  collection  of  operations  and  functors  related  to  the  diagram 
category  and  its  underlying  category.  The  colimit  operation  of  Nice  category  t/X  diagrams  is  particularly 
helpful  as  it  enables  an  aggregate  structure  to  be  developed  given  a  diagram  of  related  diagrams.  Even 
though  the  full  category  d^i  has  not  been  proved  to  be  cocomplete,  colimits  over  the  Nice  dK  diagrams  are 
sufficient  for  their  use  in  applying  and  composing  design  information  in  Chapter  6.  The  functors 
Diagramize  and  Colimit  are  obvious,  but  they  enable  the  objects  and  arrows  of  category  rfX  to  be  treated  as 
objects  and  arrows  in  category  X  and  vice  versa.  This  enables  properties  over  the  objects  and  arrows  in 
category  X  to  be  assigned  to  the  associated  objects  and  arrows  of  category  ^/X.  The  functors  are  used  in 
Chapter  4  to  assign  the  properties  and  semantics  of  category  Spec  objects  and  arrows  to  category  dSpec 
objects  and  arrows.  The  operations  Flatten  and  Partition  relate  the  diagrams  of  the  categories  X  and  ^/X 
instead  of  the  individual  objects  and  arrows.  They  enable  category  JX  diagrams  to  be  (re)partitioned  and 
manipulated  as  needed  without  losing  the  underlying  structure  as  a  diagram  in  category  X.  They  are  used 
in  Chapter  6  to  define  necessary  properties  of  diagram  interpretations  so  that  they  can  accurately  represent 
the  refinement  of  parameterized  diagrams.  Also  of  note  is  the  definition  of  an  extension  morphism  in  the 
category  dX.  along  with  the  notions  of  parameterization  and  instantiation.  They  are  used,  along  with  the 
operations  Join  and  Fold^  to  define  the  semantics  of  the  diagram  statement  developed  in  Chapter  5.  The 
generic  incarnation  of  parameterized  diagrams  in  Chapter  5  is  more  general  than  the  use  to  which  they  have 
been  put  in  this  thesis. 

A  dlird  contribution  is  the  category  dSpec  developed  in  Chapter  4  by  building  upon  the  diagram 
theory  developed  in  Chapter  3.  The  semantics  of  the  objects  and  arrows  of  category  dSpec  are  formally 
defined,  using  the  functor  Colimit,  to  be  the  same  as  the  associated  category  Spec  objects  and  arrows.  In 
fact,  this  formalization  has  enabled  dSpec  objects  and  arrows  to  be  treated  as  Spec  objects  and  arrows, 
which  means  that  much  of  the  theory  that  is  aheady  known  about  category  Spec  can  be  directly  applied  to 


162 


category  dSpec,  Thus  when  new  properties  are  attributed  to  the  objects  and  arrows  of  category  Spec  they 
can  easily  be  raised  up  to  be  properties  of  category  dSpec. 

A  fourth  contribution  is  the  parameterization  flieory  for  diagrams  that  subsumes  all  current 
(category  theory  based)  parameterization  and  instantiation  mechanisms  for  algebraic  specifications  as 
described  in  Section  2.3  and  Appendix  E.  This  formalization  of  parameterization  is  shown  to  provide  two 
distinct  advantages  over  other  forms  of  parameterization.  The  first  advantage  is  that  it  enables  the  body 
being  parameterized  to  be  a  dSpec  object  {Spec  diagrams)  instead  of  a  single  specification.  This  enables 
the  body  to  have  structure,  so  to  speak,  instead  of  having  that  structure  be  collapsed  into  a  single 
specification.  The  second  advantage  is  that  the  definition  of  a  formal  parameter  includes  additional 
constraints  beyond  those  of  being  a  conservative  extension,  which  is  the  usual  definition  of 
parameterization.  These  constraints  ensure  that  the  formal  parameter  fully  covers  the  variable  part  of  the 
body;  the  defined  formal  parameter  is  not  a  formal  parameter  (i.e.  one  of  many)  but  the  formal  parameter 
(i.e.  there  are  no  others).  This  distinction  is  important  when  reasoning  about  the  refinement  of  a  body 
diagram,  as  the  only  way  to  determine  if  the  body  refinement  has  affected  its  variable  parts  is  to  ensure  that 
a  formal  parameter  that  folly  covers  the  variable  parts  still  has  a  conservative  extension  to  the  refinement  of 
the  body.  Also  of  note  is  the  observation  that  while  formalizations  of  parameterization  in  category  Spec 
may  have  many  different  forms  (single  parameterization,  multi-parameterization,  parameterization  by  a 
diagram,  or  the  myriad  of  forms  that  parameterized  diagrams  can  have),  parameterizations  when  viewed  in 
dSpec  have  only  one  form,  (see  Figure  4-10).  This  may  enable  automated  tools  to  deal  with  the  endless 
category  Spec  forms  of  parameterization  by  dealing  with  them  on  the  dSpec  level  as  a  single  form. 

A  fifth  contribution  is  the  use  of  Spec  diagrams  as  reusable  extendable  objects  in  a  software¬ 
engineering  context.  No  longer  are  specifications,  morphisms  and  interpretations  the  largest  reusable 
objects  for  creating  Spec  diagrams.  The  use  of  parameterized  Spec  diagrams  adds  even  more  expressive 
power  and  enables  Spec  diagrams  to  be  created  using  instantiation,  which  is  imdoubtedly  a  more  natural 
and  higher-level  diagram  development  method  than  the  diagram  construction  method  of  listing  the 
diagrams  nodes  and  arcs. 

A  sixth  contribution  is  the  development  of  the  syntax  and  semantics  of  a  diagram  statement  for 
creating  and  instantiating  parameterized  diagrams.  This  bridges  the  gap  between  the  underlying  theory  and 
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its  use  in  a  software-engineering  environment.  The  syntax  of  the  diagram  statement  is  defined  in  terms  of 
the  parameterized  diagram  theory  developed  in  Section  3.5  and  Section  4,2  and  is  demonstrated  to  be 
capable  of  single  parameterization,  multi-parameterization  and  diagram  parameterization  as  well  as  nested 
and  recursive  instantiation.  In  addition,  the  parameterized  diagram  statement  is  demonstrated  to  be  capable 
of  being  partially  instantiated  so  that  larger  parameterized  diagrams  can  be  constructed  from  smaller 
parameterized  diagrams. 

A  seventh  contribution  is  the  definition  of  a  dSpec  interpretation  and  the  category  dinterp  that 
parallels  a  Spec  interpretation  and  the  category  Interp  and  that  forms  the  basis  for  representing  design 
information.  While  a  Spec  interpretation  can  insure  the  content  of  a  specification  is  refined,  a  dSpec 
interpretation  can  insure  the  content  and  structure  are  refined.  Because  of  the  relationships  between 
categories  Spec,  dSpec,  Interp  and  dinterp,  the  model  semantics  of  a  diagram  interpretation  is  also  easily 
defined.  This  dissertation  argues  that  a  diagram  interpretation  is  a  generalization  of  both  an  interpretation 
and  diagram  refinement.  As  such ,  a  diagram  refinement  could  be  replaced  by  a  diagram  interpretation  and 
the  latter  could  provide  more  refinement  capabilities.  However,  it  is  better  to  use  diagram  interpretations  to 
represent  design  information  and  let  the  diagram  colimit  mechanism  apply  the  design  information. 

An  eighth  contribution  is  the  three  classes  of  design  information  (simple,  parameterized,  and 
constrained  parameterized)  and  the  related  required  diagram  interpretation  properties  described  in  Section 
6.1.1  that  ensure  fliat  the  design  information  classes  are  correctly  represented  and  refined.  For 
parameterization  diagrams  in  general,  they  enable  the  body  part  to  be  refined  independently  of  its  formal 
parameter  part  as  guaranteed  by  the  dfriterpretation  morphism  between  the  formal  parameter  parts  and  the 
body  parts  in  the  (re)partitioned  diagram  interpretation.  For  constraints  on  the  parameter  part,  they  ensure 
that  the  constraint  on  the  domain  parameterized  diagram  is  incorporated  into  the  formal  parameter  parts  of 
the  mediator  and  codomain  diagrams.  While  notions  of  the  refinement  of  parameterized  specifications 
have  occurred  in  the  literature  [Sri97],  the  notion  of  a  constraint  on  the  parameterization  is  a  new  addition 
to  parameterization  refinement.  Constrained  parameterized  diagram  interpretations  are  a  powerful  tool  as 
they  enable  the  refinement  of  a  body  part  to  take  advantage  of  the  properties  that  are  present  in  a  particular 
actual  parameter  instantiation  in  the  requirement  specification.  The  different  forms  of  design  information 
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are  shown  to  compose,  which  means  that  larger  chunks  of  design  information  can  be  built  up  from  smaller 
pieces  and  applied  as  a  unit  instead  of  piecemeal. 

A  ninth  contribution  is  the  application  of  design  information  by  pushouts  in  dSpec.  Once  the 
preconditions  of  the  design  information  are  related  to  the  requirement  diagram,  the  design  information  can 
be  mechanically  applied  in  a  correct  manner.  While  other  researchers  have  developed  a  means  to  refine 
parameterized  specifications  [Sri97],  the  application  of  such  design  information  to  a  requirement  diagram 
was  lacking.  Incorporating  preconditions  as  part  of  the  design  application  process  ensures  that  design 
information  is  only  applied  in  situations  where  it  is  applicable.  Each  apphcation  of  design  information 
results  in  a  new  requirements  diagram  where  the  design  decisions  are  automatically  rippled  thorough  the 
diagram.  Additionally,  the  application  of  design  information  automatically  results  in  a  diagram  morphism 
between  the  old  requirements  and  the  new  requirements.  The  application  of  design  information  can  be 
done  by  a  single  design  decision  at  a  time  (with  a  pushout)  or  by  multiple  design  decisions  at  a  time  (via  a 
colimit).  The  method  of  representing  and  applying  design  information  developed  in  this  thesis  is  shown  to 
address  problems  with  the  current  techniques  for  representing  and  applying  design  information  (i.e.  Spec 
interpretations  and  diagram  refinement). 

7,2  Future  Work 

Several  items  of  future  work  were  discussed  in  the  summaries  of  the  associated  chapters.  They  are 
summarized  here  and  are  followed  by  other  more  general  observations. 

In  Chapter  3  future  work  involves  extending  the  algorithm  for  colimits  over  Nice  category  rfX 
diagrams  to  non-Nice  diagrams  (those  that  don’t  commute  and  those  that  contain  non-commuting  Spec 
diagrams  as  objects)  In  Chapter  4  future  work  involves  developing  more  and  better  means 
(mechanical/automatic)  for  determining  if  a  diagram  morphism  (and  a  Spec  morphism)  is  a  conservative 
extension.  This  is  of  great  importance  to  all  forms  of  algebraic  specification  parameterization  and  not 
limited  to  diagram  parameterization  or  the  research  presented  here.  Related  to  that  is  developing  a 
mechanical  method  for  determining  if  the  variable  parts  of  a  body  diagram  are  fully  covered  by  the  formal 
parameter.  Finally,  in  Chapter  6  future  work  involves  using  diagram  interpretations  for  other  classes  of 
design  information  beyond  the  classes  described  in  Section  6. 1 . 
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In  general,  more  experience  is  needed  in  developing  and  refining  requirement  specifications  using 
these  methods  so  as  to  learn  the  best  way  to  develop,  represent,  and  apply  the  design  information.  While 
this  research  has  provided  the  underlying  theory  of  representing  and  applying  stmctured  design  information 
and  offered  some  alternatives  such  as  diagram  interpretations  vs.  reduced-structure  diagram  interpretations, 
what  will  work  best  in  practice  has  not  been  determined.  Futhure  research  should  also  involve  new 
specification  language  syntax  (beyond  what  was  developed  in  Chapter  5  for  parameterized  diagrams)  for 
developing  and  applying  design  information  and/or  a  graphical  environment  for  doing  so. 

Finally,  this  dissertation  concentrated  on  the  data  stmcture  aspects  of  design.  The  algorithm 
choices  are  equally  important.  Methods  for  representing  and  applying  algorithm  design  information  need 
to  be  developed  and  then  integrated  v/ith  the  data  structure  methods  in  order  for  a  formal  transformation 
software  development  system  to  be  a  viable  alternative  to  traditional  methods. 
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Appendix  A.  Category  Theory 

Category  theory  is  an  abstract  mafliematical  structure  that  focuses  on  the  relationships  between 
objects  in  a  collection  and  not  on  the  objects’  internal  structure.  That  is,  an  object  is  defined  exclusively  by 
its  relationships  with  other  objects,  where  the  relationships  are  referred  to  as  arrows.  An  arrow  between 
two  objects  means  that  die  source  object’s  essential  properties,  from  the  perspective  of  the  category,  are 
preserved  in  some  way  in  the  target  object  even  though  die  internal  stractures  of  the  objects  may  be 
different.  The  focus  on  property-preserving  arrows  by  category  theory  makes  it  perfect  for  relating 
algebraic  specifications  widi  different  internal  but  similar  external  properties.  Abstracting  algebraic 
specifications  and  the  relationships  between  them  as  a  category  provides  a  means  by  which  a  rich  existing 
logic  can  be  used  to  describe  and  prove  theories  about  the  refinement  of  algebraic  specifications.  The 
following  references  were  used  when  developing  this  Appendix:  [Gol84],  [AHS90]. 

A.1  Categories 

An  axiomatic  definition  of  a  Category  is  taken  from  [Gol84]. 

Definition  A,l.  A  category  C  consists  of  the  following: 

■  A  collection  of  things  called  C-objects 

■  A  collection  of  things  called  C-arrows  (dr  C-morphisms) 

■  Operations  assigning  to  each  C-arrow /a  C-object  dom(/)  and  a  C-object  cod(/),  where  dom 
and  cod  are  called  the  domain  and  codomain  objects  of  the  arrow.  If  A  =  doni(/)  and 

B  =  cod(/)  then  we  display  this  as/ :A  B  or  A  — >  B . 

■  An  operation  assigning  to  each  pair  of  C-arrows,  — >  with  cod(/)  —  dom(  g  ),  a 
C-arrow  go/:  dom(/)  cod(  g  ),  the  composite  of/and  g,  that  satisfies  the  following 

associative  law:  Given  the  configuration  A— ^^—>B — >C  of  C-objects  and 

C-arrows  then 

ho{gof)  =  {ho  g)o/  SeeFigareA-i. 

■  An  assignment  to  each  C-object  B  a  C-arrow  idB:B  — >  B,  called  the  identity  arrow  on  B,  tiiat 
satisfies  the  following  Identity  law:  For  any  C-arrows/:  A  ->  B  and  g :  B  ->  C,  ids  °  /=/and 
goidB  =  g. 
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gof 

Arrow  composition 


ho(goj) 

(ho~g}of 


Arrow  associativity 


Figure  A-1.  Composition  and  associativity  of  arrows  in  a  category 


Notation:  Objects(C)  denotes  all  objects  in  a  category  C.  Arrows(G)  denotes  all  arrows  in  a  category  C. 
Arrowsc(A->B)  denotes  all  arrows  in  category  C  with  dom(A)  and  cod(B). 

Example  A.2.  Sets  and  the  functions  over  sets  form  a  category,  Set,  where  the  objects  are  sets  of  elements 
and  the  arrows  are  functions  that  map  the  elements  of  one  set  object  to  those  in  another. 

5e^-objects  are  sets  of  elements.  5e/-arrows  are  triples,  <dom,  cod,  map>,  where  dom  is  the 
domain  object  set,  cod  is  the  codomain  object  set,  and  map  is  a  set  of  pairs  (oc,p)  defining  a  function  that 
maps  domain  set  elements  to  codomain  set  elements. 

map  c  {(a,p)|  a  e  dom  Ape  cod} 

such  that  for  all  a  e  dom  there  exists  a  single  p  e  cod  where  (a,P)  e  map. 

Identity  arrows  for  5e^objects  are  the  triple  <A,  A,  {(a,a)|  a  e  A}>  where  A  represents  an 
arbitrary  &^-object  and  oc  an  arbitrary  element  of  A.  The  composition  and  associativity  of  functions  over 
sets  of  elements  (and  hence  arrows  in  the  category  Set)  are  well  known. 

Notation:  C-arrows  often  include  domain  and  codomain  information  in  order  to  distinguish  between 
similar  C-arrows.  For  example,  if  a  iSet-arrow  were  only  represented  by  the  element  mapping  relation  then 
there  would  be  nothing  to  distinguish  between  two  5e^a^rows  with  the  same  domain  object  and  different 
codomain  objects.  The  different  codomain  objects  can  contain  the  same  image  elements  as  well  as  some 
additional  (different)  elements.  Often  the  domain  and  codomain  information  is  left  off  of  the  arrow  as  for 
any  given  arrow  the  domain  and  codomain  objects  are  usually  obvious. 

Example  A3.  Graphs  and  graph-morphisms  form  a  category,  Graph,  where  a  graph  is  an  unlabeled, 
directed,  multigraph.  The  objects  of  the  category  are  4-tuples,  Graph-OhieoX  =  <N,  E,  source,  targeV> 
where  N  is  a  set  of  nodes,  E  is  a  set  of  arcs,  50wrce:arc^node  returns  the  source  node  of  an  arc  and 
/arge^:arC“>node  returns  the  target  node  of  an  arc.  Given  Gm/^A-objects,  Gi  and  G2,  a  graph-morphism 
/:Gi^G2  is  a  pair  of  functions  that  maps  nodes  and  arcs  of  Gi  to  nodes  and  arcs  of  G2  such  that  source  and 
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target  functions  are  consistent.  For  a  graph-morphism,/-  t®  l^e  consistent,  if  Gi  <Ni,  Ei, 

sourcex,  targeh>  and  G2  =  <N2,  E2,  sourcei,  target2>  tiien  for  all  e  e  E,,  w«rce2(fedge(e))  =fm>iisourcei{e)) 
and  target2(/'edge(e))  =faoie{targeU{t)).  Identity  arrows,  flie  composition  of  arrows,  and  the  associativity  of 
composition  can  be  proven  by  extending  the  proof  for  category  Set.  Figure  A-2  depicts  two  graphs  and  a 
graph  morphism  (dashed  arrows)  between  them.  Only  the  nodes  are  identified  in  tiie  graph  morphism  as 
(in  tbis  case)  the  mapping  of  arcs  is  unique.  In  general  there  may  be  zero  to  many  different  morphisms 
between  graphs. 


GraphA  GraphB 

Figure  A-2.  Graphical  depiction  of  two  graphs  and  a  graph  morphism  between  them 

Example  A.4.  Roughly  speaking,  a  shape  category  is  a  Graph  object  fliat  is  itself  a  category:  Each  node 
has  an  arc  to  itself,  and  whenever  there  are  adjacent  arcs,  there  is  an  arc  between  the  source  node  of  the  first 
arc  and  die  target  node  of  the  second  arc.  Thus  the  nodes  and  arcs  are  the  objects  and  arrows  of  the 
category.  An  example  of  a  shape  category  is  depicted  in  Figure  A-3.  Chapter  3  formally  defines  the  notion 
of  a  shape  category,  as  diey  are  integral  to  that  chapter. 


Figure  A-3.  An  example  shape  category 

Example  A.5.  Any  set  of  elements  with  a  reflexive  and  transitive  binary  relation  (called  a  pre-order) 
among  the  elements  is  a  category.  The  elements  of  the  set  are  the  objects  of  the  category  and  the  elements 
of  the  pre-order  relation  among  die  elements  are  the  arrows.  Thus  the  natural  numbers  are  the  objects  and 
the  relation  “less  than  or  equal  to”  are  the  arrows  of  a  particular  category.  The  same  set  of  numbers  and  the 
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relationship  “is  divisible  by”  form  a  different  category.  Figure  A-4  depicts  the  “is  divisible  by”  relationship 
between  die  natural  numbers  1-10,  where  identity  arrows  (a  number  is  divisible  by  itself)  and  composite 
arrows  are  not  depicted. 


8  10 


Figure  A-4.  An  example  natural  numbers  category 

A.2  Diagrams 

Relationships  among  select  objects  and  arrows  of  a  category  can  be  depicted  graphically  by  using 
a  diagram.  The  following  definition  of  a  diagram  is  adequate  for  its  use  in  Appendix  A  through  Appendix 
C.  The  definition  is  expanded  upon  in  Section  A.4  and  in  Chapter  3,  the  diagram  theory  chapter. 
Definition  A.6.  A  diagram  in  a  category  C,  called  a  C-diagram,  is  a  directed  graph  in  which  vertices  are 
labeled  with  C-objects  and  edges  are  labeled  with  C-arrows  where  each  edge/from  vertex  qi  to  vertex  r]2 
has  an  associated  C-arrow/:A-»  B,  where  A  is  the  C-object  associated  with  q,  and  B  is  flie  C-object 
associated  with  t|2. 

Notation:  Because  there  are  many  arrows  and  objects  in  a  given  category  one  normally  depicts  in  a 
diagram  figure  only  representations  of  those  objects  and  arrows  that  are  of  interest.  The  identity  arrow  of 
an  object  and  some  of  the  arrow  compositions  are  not  depicted  in  a  diagram  because  the  depiction  becomes 
too  unwieldy,  but  they  exist  all  the  same. 

Notation:  Typically  a  node  in  a  diagram  and  its  associated  object  have  the  same  name.  If  an  object  is 
depicted  more  dian  once  in  a  diagram,  then  the  nodes  are  given  distinct  names. 

Diagrams  are  often  used  to  state  and  prove  properties  (as  shown  in  Figure  A-1)  of  categorical 
constructions.  Following  a  sequence  of  edges  represents  arrow  composition;  the  composite  arrows  need 
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Bot  be  depicted,  as  they  always  exist.  A  walk  through  the  vertices  and  edges  of  a  C-diagram  represents  a 
unique  composite  arrow  from  the  source  object  of  the  walk  to  the  target  object  of  the  walk.  If  the 
composite  arrows  of  two  distinct  walks  that  start  and  end  at  the  same  pair  of  vertices  are  equivalent,  then 
die  walks  are  said  to  commute.  We  say  the  C-diagram  commutes  to  imply  this  equivalency  for  all  such 
walks  in  the  diagram. 

Definition  A,7*  A  C-diagram  comtnutes  if  for  all  vertices  A  and  B,  all  the  walks  from  A  to  B  )deld,  by 
arrow  composition  in  category  C,  equal  C-arrows  with  domain  A  and  codomain  B. 

An  example  of  a  non-commuting  diagram  in  category  Set  is  depicted  in  Figure  A-5;  Arrows/and 
g  have  the  same  domain  and  codomain  objects  yet  they  are  not  equivalent.  The  compositions/o  h  and 
g  °  h  are  equivalent,  however,  2is{foh)  =  {g^h)  =  Z— >3.  Neither  of  these  compositions  are  equivalent 
to  arrow  i. 


Figure  A-5.  Non  commuting  diagram  in  category  Set 


A.  3  Arrow  properties 

Some  objects  in  a  category  with  different  internal  structure  can  be  classified  as  being  abstractly  the 
same  object  within  a  category  by  virtue  of  having  the  same  external  structure.  Since  category  arrows  relate 
the  external  structure  (essential  properties)  of  objects,  one  can  define  what  it  means  to  be  abstractly  the 
same  based  on  the  arrows  between  objects  in  a  category. 

Definition  A.8.  An  isomorphism  is  a  C-arrow / :  A->B  for  which  there  exists  a  C-arrow  g:B^A  such  that 
g^f=  idA  and/o  g  =  Mb-  The  C-arrow  g  is  uniquely  defined  [AHS90]  and  called  the  inverse  off  and  is 
denoted/  *.  If  there  exists  a  C-arrow / :  A-“>B  that  is  an  isomorphism,  then  A  and  B  are  called  isomorphic 
C-objects  and  we  write  A  =  B. 
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The  concept  of  an  isomorphism  is  important  as  it  identifies  objects  that  have  the  same  structure 
(from  the  perspective  of  the  category).  This  structure  is  the  essential  property  that  the  arrows  of  a  category 
preserve  when  relating  objects  via  the  arrows.  Many  categorical  constructions  are  only  defined  up  to 
isomorphism.  There  may  be  many  isomorphic  objects  that  fit  a  given  definition  and  we  typically  pick  (or 
construct)  one  of  them  to  represent  them  all. 

Objects  in  the  category  Set  are  isomorphic  if  they  have  the  same  cardinal  number.  Sets  with  the 
same  cardinal  number  have  at  least  one  bijective  function  between  them.  The  inverse  of  a  Set-dxrow  with  a 
bijective  function  swaps  the  domain  and  codomain  and  reverses  the  map  relation  (the  inverse  of  the  Set- 
mo^  <A,  B,  {a-»|3,  etc}>  is  <B,  A,  {p->a,  v-^p,etc}>).  Any  set  can  abstractly  replace  any  other 
set  with  the  same  cardinal  number.  What  is  important  (from  die  perspective  of  the  category  Set)  is  the 
number  of  elements  in  the  set,  not  the  arbitrary  names  or  internal  structures  of  the  elements.  For  example, 
the  properties  of  the  actual  elements  of  the  isomorphic  sets  {1,2,3}  and  {a,b,c}  are  immaterial  from  the 
perspective  of  the  category  Set. 

An  arrow  can  also  have  the  effect  of  mapping  the  structure  of  one  object  to  another  in  a  manner 
that  is  similar  to  injective  or  surjective  ftinctions  in  between  sets.  These  arrow  properties  are  called  monic 
and  epic,  respectively. 

Definition  A,9.  A  C-arrow / :  A->B  is  monic  (or  a  monomorphism)  if  for  any  arrows  g:C-^A  and  h:C-^A 

h 

the  equality /»  g  =/»  h  implies  g  =  h. 

Deflnition  A.10.  A  C-arrow/;  A-^B  is  epic  (or  an  epimorphism)  if  for  any  arrows  g:B->C  and  /i:B-»C 

A 

the  equality  g  <>  /=  h  °  /implies  g^h. 

Monic  arrows  in  Set  are  injective  functions  and  epic  arrows  in  Set  are  surjections.  In  the  category 
Set,  if  an  arrow  is  both  a  monomorphism  and  an  epimorphism  it  is  an  isomorphism.  This  is  not  the  case  for 
all  categories.  Monic  arrows  are  important  in  that  Ihe  structure  of  the  domain  object  is  not  combined  or 
collapsed  somehow  in  the  structure  of  the  codomain  object.  Epic  arrows  are  inqrortant  in  that  the  domain 
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object  completely  covers  the  codomain  object,  there  is  no  additional  (external)  structure  in  the  codomain 
object. 

A.4  Functors 

Since  a  diagram  is  a  “window”  into  the  objects  and  arrows  of  a  particular  category,  we  know  that 
all  of  the  properties  (identity  arrows  and  conqjosition  of  arrows)  of  a  category  apply  to  the  objects  and 
arrows  in  a  particular  diagram  whether  they  are  depicted  or  not.  Thus  another  way  to  view  a  C-diagram  is 
as  a  particular  relationship  between  a  shape  category  and  the  category  C;  see  Figure  A-6,  where  there  is  an 
obvious  mapping  of  the  objects  (nodes)  and  arrows  (arcs)  of  the  depicted  Shape  category  to  the  selected 
objects  {A,B,C,D}  and  arrows  {/,  g,  h,  i,  idp,,  id^,  idc,  ido}  of  category  C 


a.  Shape  Category  b.  Diagram  of  objects  and  arrows 

in  Category  C 

Figure  A-6.  A  shape  category  and  a  diagram  of  objects  and  arrows  of  a  particular  category 

When  two  categories  are  related  in  a  way  that  preserves  the  object  and  arrow  structure  of  the 
source  category  in  die  target  category,  that  relationship  is  called  a  functor.  Functors  map  all  objects  and 
arrows  in  one  category  to  those  of  another  such  that  identity  arrows  and  arrow  compositions  are  preserved. 
Definition  A.11.  A  Junctor  F  from  a  category  C  to  a  category  D  is  a  pair  of  functions  F  =  <Fobject.  Fatow^ 
that  assigns  to  each  C-object  A  a  D-object  Fobject(A)  and  to  each  C-arrow/:  A  B  a  D-arrow 
Fyuiow(/):  Fobject(A)  ->  Fobj«ct(B)  such  that  the  identity  arrows  and  composite  arrows  of  category  C  remain 
identity  arrows  and  composite  arrows  in  category  D,  as  depicted  in  Figure  A-7 . 
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Fahow  (i^A  )  =  idF„,.^,(A)  for  aU  C-objects  A,  and 
FAm.w(  g  °/)  =  FAnow(  g )  »  FaitowC/)  whenever  g  o/is  defined  in  C. 
Figure  A-7.  A  Functor  preserves  identity  and  composition  arrows 


Example  A.12.  A  C-diagram  can  be  thought  of  as  the  functor  between  a  particular  shape  category  and  the 
category  C.  If  G  is  die  shape  category  depicted  in  Figure  A-6(a)  then  pair  of  functions  that  assigns  each 
object  (node)  in  G  to  a  C-object  and  each  arrow  (arc)  in  G  to  a  C-arrow  such  that  identity  arrows  and  arrow 
conqiositions  are  preserved  is  a  functor.  This  notion  of  a  diagram  as  a  fimctor  is  integral  to  Chapter  3  and 


is  further  explained  there. 

Categories  and  the  functors  between  them  are  themselves  a  category.  Cat  [AHS90].  This  can 
cause  some  “level”  confusion,  as  on  one  level  a  functor  is  between  categories  and  on  the  Cat  level  it  is  an 


arrow  between  objects. 


A.  5  Subcategory 

Subcategories  contain  a  subset  of  die  objects  and  arrows  of  anodier  category.  A  subcategory  is 
defined  in  [AHS90]  as 

Definition  A.13.  A  category  C  is  a  subcategory  of  category  D  iff 

■  Objects(C)  c  Objects(D) 

•  For  each  a,  P  e  Objects(C),  Arrowsc(a->P)  c  ArrowsD(a->p) 

■  For  each  a  e  Objects(C),  the  C  identity  arrow  of  a  is  the  D  identity  arrow 

■  For  each  a,  p  €  Objects(C),  C  composition  a  oc  P  is  a  restriction  of  D  conqiosition  a  op  p. 
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DeHnition  A.14,  A  category  C  is  a  full  subcategory  of  category  D  iff 

■  C  is  a  subcategory  of  D 

■  For  each  a,  P  g  Objects(C),  Arrowsc(a“>P)  -  ArrowsD(a-->P) 

Since  a  subcategory  is  based  upon  another  category  one  does  not  need  to  re-prove  associativity, 
composition  and  identity  properties  of  arrows.  By  specifying  its  object  class  as  a  subset  of  Objects(D),  we 
can  identify  a  full  subcategory  of  D.  We  know  this  full  subcategory  is  a  category  as  it  has  all  the  relevant 
arrows  (including  composition  and  identity)  of  its  subset  of  D  objects  and  that  these  arrows  (in  D)  have  all 
the  appropriate  categorical  properties.  With  subcategories  that  are  not  full,  we  must  be  sure  that  all  the 
relevant  arrows  are  included, 

A.6  Pushouts,  Colimits 

A  pushout,  and  the  more  general  colimit,  are  category  constructions  that  can  be  used  to  determine 
a  unique  (up  to  isomorphism)  “minimal”  object  for  a  given  diagram.  A  pushout  is  the  name  given  to  a 
colimit  over  diagrams  of  the  form  Bl<-  A  “»B2. 

Definition  A.15.  In  any  category,  X,  given  a  diagram  Bl<—  A  -^B2  where  an  object  A  has  arrows 
/A^Bl  and  g:A->B2,  the  pushout  of  the  diagram  is  an  object  C  and  arrows  /':B2-»C  and  g':Bl->C  where 
g"  ^  g  and  where  for  any  other  C-arrows  A:B2“->D  and y:Bl“>D  such  that  j  «> /=  h  ^  g  there  is  a 

unique  arrow  that  forms  a  commuting  diagram,  see  Figure  A- 8.  The  constructed  arrows  that  form 

the  pushout  square  are  also  unique.  Arrow  f  is  referred  to  as  the  pushout  of  f  along  g  and  arrow  g  *  is 
referred  to  as  the  pushout  of  g  along  / 


a.  Pushout  base  b.  Pushout  constuction  c.  Pushout  is  minimal 


Figure  A-8.  Definition  of  pushout 


175 


The  pushout  object  C,  in  Figure  A-8,  is  related  to  each  object  in  the  pushout  base  diagram  as  there 
exist  arrows  from  those  objects  to  the  pushout  object.  The  object  C  is  minimal  in  that  any  other  object  that 
forms  a  commuting  square  with  the  pushout  base  must  have  an  arrow  to  it  from  the  pushout  object. 

An  example  pushout  in  the  category  Set  is  depicted  in  Figure  A-9.  The  pushout  object  of  diagram 
{1,2,3}  4-{A,B}^{7,8,9}  is  object  {W,X,Y,Z}  and  the  arrows  to  that  object.  The  actual  elements  in  the 
pushout  object  (W,X,Y,Z)  are  arbitrary;  any  Set  with  four  elements  could  serve  as  the  pushout  set  object  as 
it  would  be  isomorphic  to  the  one  depicted.  The  interested  reader  can  construct  commuting  squares  with 
set  objects  that  have  1  through  5  elements  and  determine  if  the  given  pushout  object  in  Figure  A-9  has  a 
unique  arrow  to  it. 


2^W,  3^X}' 


{A.B} 


{W,X,Y,Z} 


Figure  A-9.  Example  pushout  in  Set 


A  pushout  is  a  specific  example  of  the  colimit  operation  that  defines  the  “minimal”  object  for  an 
arbitrary  diagram  in  category. 

Definition  A.16.  A  cocone  from  a  diagram  29  to  an  object  C  is  a  collection  of  arrows 

Di  C  I  Di  e  29}  such  that  for  any  arrow  g:Di->Dj  in  29,  fi=fjOg.  That  is,  diagram  in  Figure 
A-lOcommutes  for  all  such  diagrams  involving  objects  and  arrows  of  29  and  the  collection  of  arrows  to  C. 


Figure  A-10.  Definition  of  a  cocone 
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Definition  A.17.  A  colimit  for  a  diagram  D  is  an  object  C  along  with  a  cocone  from  ®  to  C  such  that  for 
any  ofrier  cocone  to  an  object  C’,  there  is  a  unique  arrow  from  f :  C— >C’  such  that  for  every  object  Dj  in  D, 
f.^  -fof^.  That  is,  the  diagram  in  Figure  A-1 1  commutes  for  all  such  diagrams  involving  the  objects  of  V, 
their  cocone  arrows  to  C  and  C’  and  the  unique  arrow/ :C— >C’. 


Figure  A-11.  Definition  of  a  colimit 


Some  categories  do  not  have  colimit  objects  for  arbitrary  diagrams. 

Definition  A.18.  A  category  is  said  to  be  cocomplete  it  if  has  all  colimits. 

Proposition  A.19.  A  category  that  has  an  initial  object  (an  object  that  has  an  arrow  to  every  object  in  the 
category)  and  all  pushouts  is  cocon^lete 

Proof:  This  is  a  well-known  theorem  of  category  theory  [Gol84]. 
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Appendix  B.  Specifications  and  Models 

This  appendix  presents  an  algebraic-based  view  of  a  software  requirement  specification.  ■< 
Algebraic  specification  was  introduced  in  the  mid-1970s  as  a  formal  technique  for  representing  and 
reasoning  about  data  structures  such  as  sets,  lists,  strings,  etc.,  in  an  implementation-independent  manner 
[EMC092].  The  desired  interface  and  properties  of  an  abstract  data  type  (ADT)  can  be  formally  expressed 
using  an  algebraic  specification  and  can  be  reasoned  about  independent  of  any  concrete  implementations  of 
the  ADT,  as  any  implementation  of  the  specification  must  have  (at  least)  those  properties.  This  approach  to 
representing  and  reasoning  about  data  structures  is  similar  to  the  way  that  abstract  mathematical  structures 
such  as  groups,  rings  and  fields  are  described  and  reasoned  about  in  modem  algebra. 

The  requirements  for  an  abstract  data  type  can  be  specified  using  an  algebraic  specification  by 
defining  the  ADT’s  interface  (naming  the  types  and  the  operations  involved)  and  listing  the  characteristic 
properties  of  that  ADT  (logical  characteristics  over  the  interface  elements).  As  an  example,  flie  equation 
“Insert(e,S)  =  Insert(e,(insert(e,S))”  indicates  that  inserting  something  twice  is  equivalent  to  inserting 
someftiing  once  which  is  a  property  of  the  Set  ADT  but  not  the  List  or  Bag  ADT.  When  the  logical 
characteristics  are  limited  to  the  observable  interface,  then  die  properties  of  the  abstract  data  type  are 
expressed  without  reference  to  its  internal  implementation  details.  Any  programming  language 
implementation  that  satisfies  the  properties  of  the  algebraic  specification  is  a  valid  implementation  of  the 
specification.  Because  of  fliis,  algebraic  specifications  provide  an  excellent  means  for  describing  the 
requirements  for  a  system  while  not  constraining  the  designer  to  implement  it  a  specific  way. 

One  of  the  meanings  of  a  specification  is  the  class  of  models  associated  with  that  specification.  A 
model  (often  called  an  algebra)  consists  of  a  finite  number  of  sets  of  elements  and  a  finite  number  of  typed 
ftmctions  over  the  elements  of  the  sets.  If  the  sorts  and  operations  of  a  specification  are  associated  with  the 
sets  of  elements  and  functions  of  a  model  in  such  a  way  that  all  of  the  logical  properties  in  the  specification 
are  satisfied,  then  the  functions  and  sets  of  elements  are  said  to  be  a  model  of  the  specification.  Any 
collection  of  Fortran  or  Ada  functions  can  be  abstracted  as  model  where  an  abstract  function  (input  and 
output  relations  only,  no  algorithms)  represents  a  concrete  programming  language  ftmction  and  a  set  of 
elements  represents  the  range  of  values  of  a  particular  programming  language  type.  Thus  an  algebraic 
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specification  can  be  used  to  specify  a  class  of  models  and  in  doing  so  indirectly  also  specifies  a  class  of 
programming  language  implementations  that  are  concrete  versions  of  the  models. 

A  design  decision  can  be  viewed  as  a  collection  of  additional  properties  that  an  implementation 
must  have  beyond  those  made  necessary  by  the  purely  functional  requirements.  An  algorithm  or  data 
structure  choice  is  an  example  of  a  design  decision.  The  process  of  taking  an  abstract  requirement 
specification  into  a  concrete  design  specification  is  called  refinement.  Refinement  is  finished  when  a 
programming  language  implementation  can  be  derived  from  the  design  specification. 

Section  B.l  of  this  appendix  describes  algebraic  specifications  and  Section  B.2  covers  models  of 
algebraic  specifications.  For  a  more  detailed  overview  of  algebraic  specifications,  see  [Wir90].  For  a 
different  category-theoiy-based  overview  of  algebraic  specifications,  see  [Sri90]. 

BJ  Algebraic  Specifications 

In  this  section  algebraic  specifications  are  defined  by  first  defining  the  components  of  a 
specification:  a  signature  of  sorts  and  operations,  and  axioms  that  are  logical  sentences  over  the  signature. 
This  section  also  describes  how  the  components  of  a  specification  relate  to  each  otiier:  how  axioms  are 
related  to  a  signature,  how  signature  morphisms  relate  the  signatures  of  two  different  specifications,  how 
signature  morphisms  can  be  used  to  translate  axioms,  and  how  an  entailment  system  relates  set  of  axioms. 
Finally  it  defines  specifications  and  specification  morphisms  that  ensure  that  the  properties  of  the  source 
specification  are  present  in  the  target. 

B.1.1  Signatures 

The  interface  of  an  abstract  data  type  consists  of  a  set  of  data  types  and  a  set  of  functions  over 
those  data  types.  These  types  and  functions  can  be  abstractly  described  using  a  signature  consisting  of  a  set 
of  sorts  and  a  set  of  operations  over  those  sorts.  A  signature  is  only  an  abstract  representation  of  the 
interface  and  does  not  contain  any  information  that  describes  the  functionality  of  the  abstract  data  type. 
Definition  B.l*  A  signature  S  =  <S,  Q>  consists  of  a  set  S  of  sort  symbols  and  an  indexed  family  Q  w,s  of 
sorted  operation  names  over  the  sorts  in  S,  where  for  all  operations/  g  Qw,s  with  w  =  Sj,  82,  ...  Sn,  the  set 
{si,  S2, . . .  Sn,  s}  must  be  a  subset  of  S. 
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Each  signature  Z  =  <S,  Q>  has  two  functions,  Sorts  and  Operations,  where  Sorts(L)  =  S  and 
Operations(L)  =  Q.  In  addition,  we  write /:  Si,  $2, . . .  Sn  s  to  indicate  the  sort  type  of  each/ €  Q  and  we 
use  the  sequence  [si,  S2, ...  s^,  s]  to  indicate  the  rank  off.  If  rank(/)  =  [s]  (the  singleton  sequence)  then/is 
called  a  constant  of  sort  s. 

Example  B.2.  A  simple  signature,  SET,  for  the  set  abstract  data  type  is  the  pair  of  sets: 

<{set,  E,  boolean,  nat},  {Empty:  -->set,  insert:  E,  set-^set,  in:  E,  set— ^boolean,  size:  set— >nat}> 

Example  B3.  A  simple  signature,  LIST,  for  the  list  abstract  data  type  is  the  pair  of  sets: 

<{list,  E,  boolean,  nat},  (Empty :-^list,  append:  E,  list->list,  in:  E,  list-^boolean,  length:  list-^nat}> 

B.1.2  Signature  morphisms 

Two  signatures  can  be  related  by  a  signature  morphism  if  the  sorts  and  operations  of  one  can  be 
mapped  to  the  other  in  a  way  that  preserves  the  ranks  of  the  operations.  Just  as  a  signature  cannot  describe 
the  “functionality”  of  sorts  and  operations,  a  signature  morphism  cannot  indicate  that  the  sorts  and 
operations  being  related  have  similar  “functionality”. 

Definition  B.4.  A  signature  morphism  o:  A  —>B  from  signature  A  to  signature  B  is  a  pair  of  functions 
CT  =  <as,  where  for  all  s  e  Sorts(A)  and / e  Operations{A)  there  must  exist  a  s’  e  Sorts{B)  and/’  e 
Operations(B)  respectively,  such  that  as(s)  =  s’  and  ao(/)  =/’  and  where  the  rank  of/’  is  [as(si),  as(s2), 
c^sCSnX  <ys(s)]  when  the  rank  of /is  [sj,  S2. ...,  Sn,  s]. 

Example  B.5.  The  pair  of  relations:  <{set— >list,  E->E,  boolean— ^boolean,  nat— >nat}, 

{Empty-^Empty,  insert^append,  in-»in,  size--»length}>  defines  a  signature  morphism 
SET-to-LIST:  SET^LIST. 

Notation:  In  order  to  make  it  easier  to  read  signature  morphisms,  the  mappings  between  sorts  and 

operations  with  the  same  names  are  normally  not  depicted  and  the  two  sets  (which  are  usually  disjoint)  are 
merged.  Using  this  syntax,  the  SET-to-LIST  signature  morphism  can  be  written  more  succinctly  as 
{set-»list,  insert-^append,  size->length}. 

Proposition  B.6,  Signatures  and  Signature  morphisms  form  a  category,  Sign,  where  the  objects  are 
signatures  and  the  arrows  are  signature  morphisms. 
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Proof:  The  identity  arrow  for  an  object  in  Sign  maps  the  sorts  and  operations  of  a  signature  to  themselves 
in  the  same  manner  as  the  identity  arrows  in  category  Set.  The  composition  of  arrows  a  =  <0$,  from  A 

to  B  and  a’  =  <as’,  an’>  from  B  to  C  is  a’  o  a  =  <0$  ®  as,  an’  ^  an>,  which  is  associative.  [ 

The  important  parts  of  a  signature  from  the  perspective  of  the  category  Sign  are  the  number  of 
sorts,  number  of  operations,  and  ranks  of  the  operations.  The  signature  morphism  in  Example  B. 5  is  an 
isomorphism  as  the  signature  morphism  {list-->set,  append-^insert,  length— >size}  is  the  inverse  of  the 
one  given  in  the  example.  (The  two  signature  morphisms  compose  to  yield  either  idsET  idLisr-) 
Monomorphisms  in  Sign  mean  the  domain  sorts  and  operations  are  mapped  one-to-one  to 
codomain  sorts  and  operations.  There  is  no  combining  or  collapsing  where  a  single  codomain  sort  or 
operation  is  used  to  represent  multiple  domain  sorts  or  operations.  Epimorphisms  in  Sign  mean  the  domain 
sorts  and  operations  cover  the  codomain  sorts  and  operations.  There  are  no  additional  codomain  sorts  and 
operations  that  do  not  have  an  associated  domain  sort  or  operations.  An  isomorphism  between  5zgn-objects 
can  be  viewed  as  a  signature  renaming  as  the  sort  and  operation  names  may  change  but  the  size  and  the 
rank  relations  of  the  signature  remains  the  same. 

B.1.3  Axioms 

In  order  to  specify  (and  hence  distinguish  between)  different  abstract  data  types  in  a  way  that  does 
not  overly  restrict  implementation  choices  one  must  be  able  to  describe  their  properties  independent  of  the 
internals  of  any  particular  implementation.  Logical  predicates  over  the  signature  of  the  abstract  data  type 
give  us  a  way  to  describe  properties  of  the  abstract  data  type  over  its  interface  while  not  prescribing  a 
specific  internal  structure. 

DeOnition  B.7.  A  ground  term^  for  a  signature  S  =  <S,  Q>,  is  an  element  of  Qz,  where  Qz  is  the  set  of 
sort-indexed  terms  generated  using  only  the  signature  constants  and  signature  operators  over  those 
constants.  §z  is  a  set  of  sort-indexed  sets,  §z  =  {^s,s  I  s  e  S}  where  Qz,s  is  defined  inductively  as  follows: 

■  if  c  is  a  constant  operator  of  sort  s  e  S,  then  c  is  a  ground  term  of  sort  s  and  c  e  Qz,s 

■  iff  E  Q  is  an  operation  with  rank  [si,  S2, ...  Sn,  s]  and  ti,  t2,  ...  tn,  are  ground  terms  in  ^2:,s2> 

.  •  @s,sn,  respectively,  then / (ti,  t2, . . .  U  is  a  ground  term  of  sort  s  and/ (ti,  t2, . . .  U  ^  Qu' 

Example  B.8.  The  ground  terms  for  the  signature  SET  from  Example  B.2  form  the  set  Qset  ={Empty, 

Size(Empty)} .  The  SET  operations  Insert  and  In  both  require  a  ground  term  of  sort  E  as  a  “parameter” 
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before  they  could  be  considered  ground  terms,  therefore  @set,e  is  empty  because  sort  E  has  no  constants 
defined. 

Definition  B.9.  A  term^  for  a  signature  2  =  <S,  Q>,  is  an  element  of  z(V),  where  ^(V)  is  the  set  of 
sort-indexed  terms  z,s(V)  generated  from  a  set  of  sorted  variables  V  =  {Vg  |  s  e  S}  and  signature 
constants,  and  the  signature  operators  over  those  constants  and  variables. 

T'^ay)  =  {'T z,s(V)  I  s  e  S}  where  T^x,s(V)  is  defined  inductively  as  follows: 

■  if  V  is  a  variable  of  sort  s  e  S,  then  v  is  a  term  of  sort  s  and  v  g  'I' 2,s(V) 

■  if  c  is  a  constant  operator  of  sort  s  e  S,  then  c  is  a  term  of  sort  s  and  c  g  'T z,s(V) 

■  if/  €  Q  is  an  operation  with  rank  [sj,  S2, . . .  Sn,  s]  and  ti,  ta, . . .  tn,  are  terms  in 'T z,si(V),  T' z,s2(V), 
. . i,sn(V),  respectively,  then  / (ti,  t2, . . .  in)  is  a  term  of  sort  s  and/ (ti,  t2, . . .  O  e  2:,s(V) 

Example  B.IO.  If  we  consider  e  to  be  a  variable  of  sort  E  then  for  signature  SET  from  Example  B.2 

^set({^})  =  {Empty,  Insert(e, Empty),  Insert(e,Insert(e,Empty)),  Insert(e,Insert(e,Insert(e,Empty))),..., 
In(e,Enq)ty),  In(e,Insert(e, Empty)),  In(e,Insert(e,Insert(e, Empty))), 

Size(Empty),  Size(Insert(e,Empty)),  Size(Insert(e,Insert(e, Empty))), ...}. 

The  sets  of  terms  and  ground  terms  over  a  signature  are  related  in  that  the  set  of  terms  using  no 
variables  is  the  set  of  ground  terms,  i.e.  'T^({})  =  Qx- 

An  axiom  is  a  sentence  over  the  terms  of  a  given  signature  and  additional  logical  predicates. 

(Such  as  equals,  and,  or,  not,  implies,  iff  (=,  a,  v,  -i,  =>,  o)  and  the  universal  and  existential  quantifiers 
(V,  3)  and  the  bound  variables  they  introduce.)  The  definitions  for  axiom  sentences  (terms  over  logical 
predicates  and  quantifiers)  are  similar  to  the  inductive  definitions  given  in  Definition  B.7  and  Definition 
B.9.  The  exact  definition  for  the  axiom  sentences  is  dependent  on  the  particular  logic  one  wishes  to  use 
(equational  logic,  conditional  equational  logic,  first  order  logic,  etc.)  for  describing  abstract  data  type 
properties.  There  are  many  different  kinds  of  restrictions  one  can  place  on  axiom  sentences  in  terms  of 
permitted  logical  predicates,  quantifiers  and  syntactic  sentence  forms  so  that  the  axiom  sentences  are 
associated  with  a  particular  logic. 
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The  following  list  demonstrates  three  of  the  most  common  logics  used  in  algebraic  specification: 

■  Equational  logic  size(empty)  =  0 

size(prepend(x,  a-seq))  =  1  +  size(a-seq) 

■  Conditional  Equational  logic  m(x,  a-set)  =>  (size(insert(x,  a-set))  =  size(a-set)) 

not(in(x,  a-set))  =>  (size(insert(x,  a-set))  =  1  +  size(a-set)) 

■  First-Order  logic  size(a-set)  =  0  <=>  V  x.element  |  not(in(x,  a-set)) 

Restricting  the  logic  affects  the  expressiveness  in  terms  of  what  can  be  said  as  well  as  how  easy  it 
can  be  said.  Restricting  the  logic  may  enable  a  more  efficient  reasoning  system  or  have  odier  interesting 
properties.  For  exanqjle  a  term  rewriting  system  that  enables  a  specification  to  be  executed  or  interpreted 
directly  requires  equational  logic  or  conditional  equational  logic  [Klop92].  If  computability  is  the  primary 
concern  then  equational  logic  with  hidden  functions  has  been  shown  to  be  sufficient  for  describing  all 
computable  algebras  [MG84].  However,  the  need  for  hidden  functions  means  that  an  internal  structure  is 
specified  along  with  the  external  behavior.  In  addition,  some  properties  that  are  simple  to  describe  using 
higher  order  logic  are  quite  complex  when  described  using  a  lower  order  logic,  such  as  equational  logic. 

On  the  other  hand,  higher  order  logics  may  not  have  complete  proof  systems,  which  makes  proving 
properties  about  sets  of  axiom  sentences  more  difficult. 

Rather  then  relying  on  a  particular  logic  and  defining  exactly  what  is  meant  by  an  axiom,  we 
assume  that  for  every  signature  S  there  exists  a  well-formed  and  well-sorted  set  of  sentences  over  diat 
signature  called  Z-sentences.  The  axioms  describing  an  abstract  data  type  with  a  signature  of  S  are  a  subset 
of  the  S-sentences.  The  collection  of  S-sentences  for  all  possible  signatures  and  the  translation  mappings 
between  fliese  sets  of  S-sentences  form  a  subcategory  of  the  category  Set. 

B.  1 .4  Axiom  translation  over  a  signature 

Two  categories,  such  as  Sign  and  Set,  can  be  related  by  an  operation  that  maps  objects  in  one 
category  to  those  in  another  in  a  way  that  preserves  the  arrows  between  the  objects.  If  there  is  a  morphism 
between  Z  and  Z’  in  the  category  Sign  it  makes  sense  that  there  be  a  relationship  between  the  sets  of 
Z-sentences  and  Z’-sentences.  A  functor  between  the  Sign  category  and  the  Set  category  captures  that 
relationship. 


183 


Proposition  B.ll.  The  pair  of  functions  <  iSewobjecb  Arrow  >  is  a  functor  Sen:  Sign  ->  Set  where  5ewobject 
maps  each  signature  object  E  in  Sign  into  the  S-sentences  object  in  Set  and  Arrow  maps  the  signature 
morphism  arrow  a:A->B  in  Sign  into  the  function  that  translates  A-sentences  to  B-sentences  in  in  a 
manner  that  is  consistent  with  the  signature  mapping. 

Proof:  For  any  id^  in  Sign,  ^ewAirowCids)  translates  E-sentences  to  S-sentences  therefore 
‘S'e«AiTow(idi)  =  ^(2)  aiid  Sen  preserves  identity  arrows.  If/and  g  are  composable  signature 

morphisms  in  Sign  then  5enAiTow(  8  translates  sentences  from  the  domain  of  /to  the  codomain  of  g. 

This  is  equal  to  SewArrowC  g  )  ®  SenAno^(f),  which  is  the  composition  of  two  translation  functions.  □ 

Example  B.12.  5e/2object(SET)  and  5enobject(LIST)  map  the  ^zgn-objects  SET  and  LIST  (from  Example  B.2 
and  Example  B.3)  to  their  sets  of  well-formed  sentences,  SET-sentences  and  LIST-sentences,  in  the 
category  Set.  The  5ign-arrow  SET-to-LIST:  SET  LIST  is  mapped  by  Arrow  to  a  5e/-arrow  that 
translates  SET-sentences  to  LIST-sentences,  i.e.  5e«ArTow(SET-to-LIST):SET-sentences^LIST-sentences. 
Thus  the  Set-mow  iSenArrowcSET-to-LIST),  when  used  as  a  function,  maps  the  Sen(SET)  element 
“V  ^:set,  e:E  \  in(e,insert(e,5))”  to  the  ^^//(LIST)  element  “V  s’Aist,  e:E  \  in(e,append(e,.s))”. 

B.1.5  Entailment 

In  order  to  prove  properties  about  an  abstract  data  type  based  on  existing  properties  it  is  important 
to  be  able  to  prove  relationships  between  sets  of  sentences  in  a  given  language.  A  proof  calculus  for  flie 
particular  logic  underlying  the  S-sentences  is  needed  (such  as  natural  deduction  being  the  proof  calculus  for 
first  order  predicate  logic  [Man74]).  Rather  then  limiting  ourselves  to  a  particular  logic  or  proof  calculus 
we  define  an  entailment  system  that  abstracts  away  from  the  particulars  of  any  specific  logic  and  proof 
calculus.  An  entailment  relation  is  used  to  assert  that  a  sentence  is  provable  from  a  set  of  sentences  but 
does  not  prescribe  the  logic  imderlying  the  sentences  or  the  calculus  by  which  the  sentence  is  proved.  The 
following  definition  for  an  entailment  system  is  based  on  [Mes89]. 

Definition  B.13.  An  entailment  system  is  a  triple  !E=  <Sign,  Sen,  l->  with  Sign  and  Sen  defined  as  above 
and  h  a  family  of  functions  associated  with  each  S  in  Sign  such  that  each  \-^:T(Sen(L))  Sen(L)  called 
E-entailment  has  the  following  properties: 
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■  Reflexivity:  for  any  a  e  Sen(L),  {a}  hx  a; 

If  we  assume  a  sentence  we  can  prove  it 

■  Monotonicity:  if  Fhx  a  and  F  c  F’  then  F’  hz  a; 

If  a  sentence  can  be  proved,  then  it  can  also  be  proved  with  more  assumptions 

■  Transitivity:  if  F  hx  a  and  F  u  {a}  hx  P  then  F  hx  P; 

Using  a  proved  sentence  as  an  additional  assumption  cannot  enable  more  things  to  be  proved 
(although  in  any  given  proof  calculus  it  may  make  the  proof  “easier”) 

■  I— translation:  if  F  Hx  a,  then  for  any  H:I  ->  2’  in  Sign,  //(F)  l-x*  //(a)where  = iSe«Arrow(H); 
The  entailment  relation  is  consistent  under  translation  from  one  signature  to  another 

B,  1 .6  Specifications 

A  signature  2  can  describe  the  interface  signature  of  an  abstract  data  type.  A  set  of  axioms, 

Ax  c  Sen(2),  can  describe  the  abstract  properties  (functionality)  of  an  abstract  data  type.  A  specification 
combines  a  signature  and  a  set  of  axioms  over  that  signature.  Together  they  can  describe  the  interface  and 
the  properties  that  any  inqilementation  of  the  specification  must  have. 

Definition  B.14.  A  specification  A  =  <2,  Ax>  (or  <S,  Q,  Ax>)  consists  of  a  signature  2  and  a  set  of 
axioms  Ax  c  Sen(2)  where  Signature{A)  =  2,  Sorts{A)  =  S,  Operations(A)  =  Q,  and  Axioms(A)  =  Ax. 
Example  B.15-  A  simple  specification  for  the  Set  Abstract  Data  type  is  <{set,  E,  nat,  boolean}, 
{Empty:->set,  Insert:  E,  set->set,  In:  E,  set-^boolean,  Size:set  nat}, 

{“V  e:E  not(in(e, Empty))”,  “V  s:Set,  a,b:E  m{a,msGXt(b,s))  =>  ((a^b)  v  in(a,5))”,  etc.}>. 

Notation:  In  order  to  present  a  specification  in  a  more  readable  fashion,  we  adopt  the  syntax  in  Figure 
B-1.  This  syntax  is  a  slight  adaptation  of  the  Specware  language  [SLM98].  Note  that  the  sorts  Boolean 
and  Nat  are  fully  defined  and  implicit  in  the  underlying  logic.  Note  also  that  each  axiom  is  (individually) 
quantified  by  the  single  “Forall”  context  clause: 
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Spec  Set  is 
sort  Set,  E 


op  Empty: 

-> 

Set 

op  Insert 

:  E, 

Set  -> 

Set 

op  In: 

E, 

Set  -> 

Boolean 

op  Size: 

Set 

-> 

Nat 

Forall  s : 

Set, 

e, el, e2 

!  :E 

Ax  not (In (e, Empty) ) 

Ax  in{el, Insert {e2,s) )  =>  {{el=e2)  v  In(el,s)) 

Ax  Size (Empty)  =0 

Ax  Sizednsert  (e,s) )  =  if  In(e,s)  then  Size(s) 

else  Size(s)  +  1 

end-spec 


Figure  B-1.  Simple  Set  specification 

A  distinction  is  made  between  the  axioms  that  are  part  of  a  specification  and  the  S-sentences  that 
can  be  proved  from  those  axioms.  If  specification  A  =  <E,  Ax>  and  Ax  (3  where  P  e  Sen(E)  then  we 
consider  P  to  be  a  theorem  of  specification  A.  All  axioms  of  a  specification  are  also  theorems  of  the 
specification  because  of  the  reflexivity  and  the  monotonicity  of  I- 2. 

Definition  B,16.  The  closure  of  die  set  of  axioms,  Ax,  for  a  specification  A  =  <Z,  Ax>  with  respect  to  f-j 
is  the  set  Ax*  =  {a|Ax  a}.  By  definition,  Ax  c  Ax*  c  5ewobject(S). 

Definition  B-1 7.  A  theory  is  a  specification  in  which  the  axioms  are  closed  under  entaihnent. 
Specification  <E,  Ax>  is  a  presentation  of  the  theory  <L,  Ax*>. 

There  may  be  many  different  presentations  for  a  given  theory. 

As  an  aside,  a  model-based  approach,  in  contrast  to  the  algebraic  (property-based)  approach,  does 
not  have  logic-based  axioms.  Instead  of  logic,  a  reference  model  is  used  like  sets,  sequences  or  relations 
and  the  axioms  refer  directly  to  those  concepts  and  describe  operations  in  terms  of  their  explicit  effect  on 
state  (often  using  pre  and  post  conditions). 


B.  1 .7  Specification  morphisms 

A  specification  morphism  is  a  relationship  between  source  and  target  specifications  in  which  the 
target  specification  has  at  least  as  much  structure  (interface  and  properties)  as  the  source.  A  specification 
morphism  is  a  signature  morphism  between  the  signatures  of  the  specifications  where  all  the  (translated) 
axioms  of  the  source  specification  are  theorems  of  the  target  specification.  This  mapping  insures  that  the 
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interface  (signature)  of  an  abstract  data  type  is  preserved  and  the  properties  (axioms)  over  that  interface  are 
preserved.  Thus  if  the  source  specification  represents  the  requirements  for  a  system  and  the  target 
represents  the  implementation,  then  the  existence  of  a  specification  morphism  between  them  is  proof  that 
the  implementations  meets  all  the  specified  requirements. 

Deflnition  B.18.  A  specification  morphism  a:  A  ->  B  for  A  =  <S,  Ax>  and  B  =  <21’,  Ax’>  is  a  signature 
morphism /:  S  ^  I’  in  which  for  all  a  e  Ax,  Ax’ 

where /  =  SenAno^if)  is  a  function  that  translates  2-sentences  to  S’-sentences. 

In  Figure  B-2,  there  is  a  signature  morphism,  a,  from  specification  Set  to  specification  List 
indicated  by  the  pair  of  relations  <{Set^List},  {Insert— > Append} >.  The  first  three  (translated)  axioms  of 
specification  Set  are  obviously  theorems  of  specification  List.  However,  the  last  axiom  of  specification  Set 
is  not  a  theorem  of  specification  List  (in  any  reasonable  entailment  system)  and  therefore  the  signature 
morphism  is  not  a  specification  morphism.  Since  there  are  no  other  signature  morphisms  from  Set  to  List 


there  are  no  specification  morphisms  from  Set  to  List. 


Figure  B-2.  Signature  morphism  Set  ->  List 


Although  there  is  also  an  inverse  2-morphism  from  specification  List  to  specification  Set  there  are 
no  specification  morphisms  in  that  direction  either  because  the  last  List  axiom  is  not  a  theorem  (after 
translation)  of  the  Set  specification.  In  practical  terms,  an  implementation  of  the  List  specification  can  not 
be  used  to  implement  the  Set  specification  (and  vice  versa)  without  being  extended  somehow.  The  last 
axioms  in  both  specifications  indicate  the  set  operations  /n,  Insert  and  Size  interact  in  a  different  way  than 
the  Ust  operations  In,  Append  and  Size  interact  and  thus  the  interface  of  one  cannot  be  directly  used  to 
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implement  the  other.  As  shall  be  illustrated  in  Appendix  C,  one  must  often  extend  a  specification  in  order 
for  it  to  be  a  suitable  target  for  a  specification  morphism. 

In  Figure  B-3  the  signature  morphism  from  Bit  to  Bool,  {Bit^Bool,  Toggle-^Not,  O^False, 
i->True},  is  also  a  specification  morphism  as  the  axioms  of  specification  Bit  are  theorems  of  specification 
Bool.  Interestingly  enough,  the  signature  morphism  that  assigns  the  constant  functions  0  and  1  to  Tme  and 
False  respectively  is  also  a  specification  morphism  leading  to  the  realization  that  assigning  0  to  false  and  1 
to  tme  are  arbitrary  choices. 


Figure  B-3.  Specification  morphism:  Bit  Bool 


There  is  no  signature  or  specification  morphism  from  specification  Bool  to  specification  Bit 
although  one  could  (manually)  extend  specification  Bit  with  additional  operations  to  make  such  a  signature 
and  specification  morphism  possible. 


B.  1 .8  The  category  Spec 

Proposition  B.19.  Specifications  and  specification  morphisms  form  a  category.  Spec,  where  the  objects 
are  specifications  and  the  arrows  are  specification  morphisms. 

Proof:  We  already  know  that  the  signature  portion  of  a  specification  forms  a  category  Sign,  Therefore  we 
concentrate  on  the  axioms  and  assume  that  for  every  specification  A  there  is  a  iSign-object  A  and  for  every 
specification  morphism / :  A->B  there  is  a  5r^-arrow / :  A--»B. 

Identity  Arrows:  The  identity  arrow  for  each  specification  A,  idA,  is  the  identity  signature  morphism,  idA, 
for  A  as  ^ewAnowCidA)  translates  A-sentences  to  A-sentences  (which  is  essentially  a  no-op)  and  each  axiom 
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of  A  is  trivially  a  theorem  of  A  by  the  reflexivity  of  H,  i.e.  5en  Arrow(idA)  -  id(5enobject(A)). 

Arrow  Composition:  For  specification  morphisms  f :  A^B  and  there  is  always  a  specification 

morphism  g  ®/:  A->C  as  the  underlying  signature  morphisms  compose  (i.e.  g  ®/:  A->C)  and  the 
entailment  relation  is  transitive  across  specification  morphisms,  i.e. 

axioms(B)  l-signature(B)  /(axioms(A))  o  Given 

axioms(C)  hsignature(Qg^(axioms(B))  ®  Given 

g,  (axioms(B))  Hsignature(C)  gt(  yr(axioms(A)))  [--translation  and  O 

axioms(C)  l-signature(C)  gti  /(axioms(A)))  monotonicity  of  h,  transitivity  of  h,  and. .0 

axioms(C)  l-signature(C)  (  gt  ^  ^(axioms(A))  composition  of  ^e/-arrows 

Where  the  functions  ft  and  g,  translate  A-sentences  to  B-sentences  and  B-sentences  to  C-sentences 
respectively,  i.e.^  =  Senj^J^f)  and  g,  =  ^S'enArrowCg)- 

Arrow  Associativity:  Given  specification  morphisms  f :  A— >B,  g:B->C,  and  h:C-^D  then 
ho{gof)^{hog)of2Lsiht  underlying  signature  morphisms  h  o  {g  o  f)^{h  o  g)  o/are  associative  and 
we  have  just  proven  that  specification  morphisms  compose. 

In  several  places  above  we  have  discussed  the  signature  of  a  specification  or  the  signature 
morphism  between  two  specifications.  This  relationship  between  specification  and  signature  is  captured  by 
the  fimctor  between  the  Spec  and  Sign  categories.  The  functor  Sig:Spec—>Sign  is  a  forgetful  functor  that 
maps  Spec  objects  to  Sign  objects  by  dropping  the  axioms  from  a  specification  and  maps  Spec  arrows  to 
Sign  arrows  using  the  underlying  signature  morphism.  Forgetful  functors  make  it  possible  to  expose  the 
structure  of  objects  and  arrows  in  a  category  by  relating  a  structured  category  to  a  simpler  one  by  forgetting 
some  of  the  structure. 

As  categories  and  functors  are  the  objects  and  arrows  of  a  category  Cat  [AHS90],  functors  can  be 
composed.  We  define  SeniSpec^Set  to  be  Sen:Sign-^Set  o  Sig.Spec-^Sign  as  depicted  in  Figure  B-4. 

Note  die  overloading  of  the  name  Sen  (i.e.  Sen\Spec->Set  and  Sen:Sign->Set). 
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Spec 

Objects:  Specifications 
Arrows:  Specification  Morphisms 


Sig:  Spec  — >  Sign 


Sign 

Objects:  Signatures 
Arrows:  Signature  Morphisms 


Cat 


Sen:  Spec  ->  Set 

Spec  objects  are  mapped  to  sets  of  U-sentences 
arrows  are  mapped  to 

JS-sentence  to  F-sentence  translators 


Sen:  Sign  Set 


Set 

Objects:  Sets 
Arrows:  Element  function  maps 


Sign  objects  are  mapped  to  sets  of  ^-sentences 
Sign  arrows  are  mapped  to 

F-sentence  to  F-sentence  translators 


Figure  B-4.  Algebraic  categories  and  the  Sen  Functors 


An  isomorphism  in  Set  is  based  on  the  number  of  elements  in  the  domain  and  codomain 
jSe^-objects  being  the  same.  An  isomorphism  in  Sign  is  based  on  the  structure  of  the  signature  (sorts, 
operations,  and  operation  ranks)  in  the  domain  and  codomain  .Sign-objects  being  the  same.  For  Spec,  an 
isomorphism  is  based  on  the  signature  as  well  as  what  can  be  proved  from  the  axioms.  In  Spec,  if  there  is  a 
signature  isomorphism  between  two  specifications  and  the  axioms  of  one  can  be  used  to  prove  the  axioms 
of  the  odier  (and  vice-versa)  then  there  is  an  isomorphism  between  them.  Another  way  of  stating  this  is 
that  two  specifications  are  isomorphic  if  their  (translated)  theories  are  the  same. 

Category  theory  enables  us  to  consider  two  specifications  with  isomorphic  signatures  but  different 
axioms  to  be  isomorphic  when  the  entailment  relation  enables  the  axioms  to  prove  the  same  theory.  This  is 
one  method  by  which  we  can  add  design  mformation  to  a  specification  without  changing  its  meaning 
(theory).  One  set  of  axioms  can  abstractly  define  an  input/output  relation  for  a  function.  A  different  set  of 
axioms  can  concretely  define  the  same  input/output  relation  “algorithmically”.  Both  sets  of  axioms  can 
generate  the  same  theory.  Because  the  entailment  relation  is  monotonic  and  transitive  we  do  not  have  to 
generate  and  relate  both  theories,  merely  prove  that  each  set  of  axioms  entails  the  other. 
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B,2  Models 


In  this  section  the  relationship  between  algebraic  specifications  and  models  is  defined.  An 
algebraic  specification  can  be  viewed  as  a  formal  requirement  document  as  the  models  that  satisfy  the 
requirement  specification  are  the  possible  (abstract)  implementations  of  those  requirements.  When 
specifying  requirements  it  is  important  that  the  models  associated  with  a  specification  include  all  desired 
implementations  and  exclude  those  that  are  not  desired.  In  general  this  may  be  difficult,  as  determining  if  a 
model  is  desired  is  at  heart  a  validation  problem  instead  of  a  verification  problem.  A  design  decision  adds 
additional  properties  to  the  specification  and  may  reduce  the  class  of  models  associated  with  the 
specification.  An  objective  of  refinement  (and  design)  is  to  reduce  the  class  of  models  by  imposing 
additional  structure  and  constraints  on  the  implementation  while  preserving  all  of  the  original  properties. 

A  concrete  implementation  such  as  a  set  of  FORTRAN  or  Ada  subprograms  over  intrinsic  or 
constructed  data  types  is  also  a  model.  Such  concrete  implementations  are  the  ultimate  goal  of  refinement 
but  are  too  restrictive  to  work  with  and  reason  about  as  requirements  because  of  their  syntactic  baggage  and 
operational  semantics. 

In  this  section  specification  models  are  defined  by  first  defining  signature  models  and  signature 
model  homomorphisms,  which  are  the  models  associated  with  a  signature  and  the  arrows  between  those 
models.  Signature  model  categories  and  the  reduct  functors  between  them  are  defined  in  a  way  that  is 
parallel  to  the  signatures  and  signature  morphisms  from  which  they  are  derived.  Finally  satisfaction  is 
defined  as  the  relationship  between  a  signature  model  and  a  signature  sentence  and  a  specification  model  is 
defined  as  a  signature  model  that  satisfies  all  of  the  axioms  of  a  specification.  Each  specification  has 
associated  with  it  a  restriction  of  its  signature  model  category  and  each  specification  morphism  has 
associated  with  it  a  restriction  of  the  reduct  functor  between  the  signature  model  categories. 

B.2. 1  Signature  models 

Definition  B.20.  A  signature  model,  also  called  an  Z-model,  consists  of  a  sort-indexed  collection  of  carrier 
sets  and  functions  over  those  sets,  one  for  each  sort  and  operation  in  2,  that  are  rank  consistent.  Thus  if 
I  ^  <S,  Q>  then  a  2-model  =  <As,  Fa>  where  As  =  {As  |  s  g  S}  is  the  set  of  carrier  sets  indexed  by  s  e  S 
and  Fa  =  {A  |/e  Q}  is  the  set  of  flmctions  associated  with  each  /e  Q  such  that  if  the  rank  of/is  Si,  $2, 
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Sn  — >  s  then  the  function yX  is  from  x  x  . . .  x  A^^  to  As,  where  x  is  the  Cartesian  product  of  sets. 

The  collection  of  S-models  for  a  given  2  is  denoted  by  Mod(2). 

The  definition  for  signature  models  does  not  constrain  the  carrier  sets  in  terms  of  the  number  or 
type  of  elements,  nor  does  it  constrain  the  functions  over  those  sets  in  terms  of  their  functionality.  Because 
of  this  lack  of  constraint,  most  signature  models  are  not  what  is  wanted  as  a  possible  implementation  of  a 
specification. 

As  an  example,  the  signature  BOOL  =  <{Bool},  {Tme:-^Bool,  False:^Bool,  Not:Bool— >Bool}> 
has  one  sort  and  three  operations,  two  of  which  are  constants.  There  are  an  mfimte  number  of  models  in 
Mod(BOOL)  besides  die  standard  one. 

Example  B.21.  In  the  so-called  standard  model  for  signature  BOOL,  the  carrier  set  for  sort  Bool  has  two 
elements.  The  operators  associated  with  True  and  False  return  different  Bool  carrier  set  elements.  The 
value  of  the  function  Not  returns  the  element  not  supplied  as  a  parameter. 

Model  BOOLstandard  =  Bool  ^  {0,1}  where  True  ^  1,  False  ^  0,  Not(l)  ^  0,  Not(0)  ^  1 
Example  B.22.  In  the  so-called  final  model  for  signature  BOOL,  the  carrier  set  for  sort  Bool  has  one 
element  (value).  Both  function  constants  return  this  element  as  does  the  function  Not. 

Model  BOOLpinai  =  Bool  =  {1}  where  Tme  ^  1,  False  ^  1,  Not(l)  ^  1 
Example  B,23.  In  a  so-called  loose  model  for  signature  BOOL,  the  carrier  set  for  sort  Bool  has  three 
elements.  The  constant  functions  True  and  False  return  different  Bool  elements.  The  Not  operation 
“swaps”  the  bool  carrier  set  values  of  0  and  1  and  merely  echoes  the  value  of  ±. 

Model  BOOLloosc  =  Bool  ^  {0,l,l}where  True  ^  1,  False  ^  0,  Not(l)  ^  0,  Not(0)  ^  1,  Not(l)  ^  1 
Example  B.24.  In  a  different  so-called  loose  model  for  signature  BOOL,  the  carrier  set  for  sort  Bool  has 
four  elements.  True  and  False  return  different  Bool  elements  and  the  function  Not  has  “odd”  functionality 
as  shown  below. 

Model  BOOLodd  =  Bool  ^  {0,l,a,p  }where  True  ^  1,  False  ^  0,  Not(l)  ^  1,  Not(0)  ^  a,  Not(a)  ^  0, 
Not(P)  =  p 

All  four  example  BOOL-models  are  valid  implementations  of  the  signature  BOOL.  The  labels 
initial,  final  and  loose  are  based  on  the  terms  that  can  be  generated  for  a  given  signature.  As  can  be 
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extrapolated  from  these  examples,  even  simple  signatures  such  as  BOOL  have  an  infinite  number  of 
models.  Only  some  of  these  models  are  interesting  and  useful. 

All  models  in  a  given  Mod(E)  have  carrier  sets  and  functions  that  relate  to  the  same  signature  but 
have  differing  elements  in  their  carrier  sets  and  differing  functions  over  those  earner  sets.  It  makes  sense  to 
relate  the  Z-models  in  Mod(S)  based  on  these  differing  features.  A  I-homomorphism  is  a  mapping 
between  the  elements  of  the  signature-related  carrier  sets  of  two  2-models  in  a  way  that  is  compatible  with 
all  of  the  signature-related  functions. 

B.2.2  Signature  model  homomorphisms 

Definition  B.25.  Given  a  signature  2  =  <S,  Q>  and  two  2-models  A  =  <As,  Fa>  and  B  =  <Bs,  Fb>,  a 
signature  homomorphism,  also  called  a  J^homomorphism,  h:A—>3  is  a  family  of  sort-indexed 
functions  { As! As->Bs  |  s  €  S}  between  the  carrier  sets  (mapping  their  elements)  such  that  the  operations  over 
the  carrier  set  elements  are  compatible.  More  formally,  for  all  O  operations/ :  Si,  S2, ...  Sn  s,  and  the 
associated  A  and  B  2-algebra  functions/^:  Ag^  x  Ag^  x  ...  x  Ag^  to  Agand^:  Bg^  x  Bg^  x  ...  x  Bg^  toBg, 

and  for  all  carrier  set  elements  ai  €  Ag^  a2  e  Ag^  Ag^ 

The  four  example  models  for  the  signature  BOOL  given  above  have  several  2-homomorphisms 
between  them. 

Example  B.26.  The  2-homomorphism  between  BOOLstandard  and  BOOLpinai  is 

h  (  /^Bool  1  ^Bool(^Standard)  1  Final  ^  ^Bool  (1  Standard)  1  Final} 

as  for  all  b  e  Bool;  ABooi(Truestandard)  ="  Truepmab  ^Booi(Falsestandani)  =  Falsepmab  and 

^Bool(Notstandard(b))  ~  NotFinal(ABool(b)). 

Example  B.27.  The  2-homomorphism  between  BOOLstandard  and  BOOLloosc  is 

h~  {  AbooI  I  ^Bool(^Standard)  “  ^Loose  ^  ^BoolC  1  Standard)  ~  1  Loose} 

as  for  all  b  e  Bool,  ^BooiCTruestandard)  =  TrucLoose,  etc. 
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Example  B.28.  The  S-homomoiphism  between  BOOLodd  and  BOOLpinai  is 

I  ^Bool(^Odd)  i  Final  ^  ^Bool(iodd)  ““  i  Final  ^  ^Bool(^Odd)  ~  i  Final  ^  ^Bool(Podd)  1  Final  } 

as  for  all  b  g  Bool,  ABooi(Trueodd)  -  Truepmai,  etc. 

There  is  no  S«homomorphism  AiBOOLloosc  BOOLstandard  as  the  BooIloosc  element  1  cannot  be 
mapped  to  either  Boolstandani  element  so  that  the  equation  A(NotLoose(J-))  =  Notstandard  (A(l))  is  true.  Note 
that  the  carrier  set  elements  are  defined  in  and  by  the  model.  The  choice  of  0,  1  and  JL  as  the  symbols  of  the 
carrier  set  elements  are  “syntactic  conveniences”  and  do  not  convey  a  deeper  meaning  in  and  of 
themselves. 

B.2.3  Signature  model  categories 

The  collection  of  S-models  and  the  Z-homomorphisms  between  them  are  a  category  of  Z-models. 
The  initial  model,  if  one  exists,  has  an  arrow  from  it  to  all  other  models.  The  final  model,  if  one  exists,  has 
an  arrow  to  it  from  all  other  models. 

Proposition  B.29.  Z-models  and  Z-homomorphisms  form  a  category,  Mod(I),  where  the  objects  are 
Z-models  and  the  arrows  are  Z-homomorphisms. 

Proof:  Assume  that  for  a  signature  Z  =  <S,  Q>  there  exist  arbitrary  Z-models  A  =  <As,  Fa>, 

B  =  <As,  Fb>,  C  =  <Cs,  Fc>,  and  D  =  <Ds,  Fd>  with  Z-homomorphisms  A:A->B,y:B->C,  and  A::C->D. 
Identity  Arrows:  The  identity  Z-homomorphism  is  the  collection  of  identity  functions  for  each  carrier  set  of 
Sorts(Z)  associated  with  each  Z-model  object.  These  identity  arrows  map  the  carrier  set  elements  to 
themselves,  i.e.  the  identity  Z-homomorphism  idA  =  {hs  |  s  g  S  where  for  all  a  g  As,  hs(a)  =  a)} 

Arrow  Composition:  for  the^,^,  and^c  functions  associated  with  all/e  Q  and  all  elements  ai,  a2, . . .  an 
and  bi,  b2,  . . .  bn  associated  with  each  of  the  carrier  sets  Si,  S2, . . .  Sn  e  S  in  models  A  and  B 
As(/A(ai.a2v,a„))  =  /B(As,(ai)Aj(a2).-,*s„(an)) 

7s(/B(bi.b2,...,b„))  =  /cOs,(bi),4(b2),...,4(b„))  Givm 

h  (/b  (*s,  (ai ),  K,  (32 \  (a„ )))  =  /c  (A,  (As,  (ai  )),j^  iK,  (82  ))v,4  i-K  (^n )))  Substitution 

7s(As(/A(ai,  32,...,  a„)))  =  /c(^  {\  (aO),  4  (^  (82)),...,  4  (4  (an )))  Substitution 


194 


L-homomorphisms  compose  as  functions  over  sets  compose. 

Arrow  Associativity:  Through  reasoning  similar  to  that  for  arrow  composition,  and  because  functions  over 
sets  are  associative,  2-homomorphisms  are  associative. 

Isomorphisms  in  the  category  Mod(I)  are  “translations”  of  carrier  set  elements  and  fimctions.  For 
example  the  model  BOOLs,3„dard-2  =  Bool  ^  {p  ,v}  where  Trae  M  p,  False  ^  v,  Not(p)  ^  v,  Not(v)  ^  p  is 
isomorphic  to  die  model  BOOLstmdari  hi  Exanqile  B.2 1 .  A  monomorphism  is  a  one  to  one  mapping  of 
carrier  set  elements.  An  epimorphism  has  every  target  carrier  set  element  mapped  to  by  at  least  one  source 
carrier  set  element. 

Mod(2)  has  as  objects  all  models  of  a  given  signature  S.  However,  as  we  shall  see  when  we  get  to 
models  of  specifications  only  a  subset  of  those  models  are  of  interest. 

B.2.4  Reduct  functors 

If  there  is  a  signature  moiphism,/ :  A-^B,  how  are  the  S-models  of  A  and  B  related?  There  is  a 
mapping  from  the  sorts  and  operations  of  signature  A  to  the  carrier  sets  and  functions  of  each  B-model 
because  of  the  signature  morphism/ :  A--»B.  If  unmapped  carrier  sets  and  functions  are  removed  from 
each  B-model,  then  what  is  left  must  be  an  A-model. 

Definition  B30.  Given  a  signature  A  =  <S,  Q>,  a  signature  morphism  a:A^B  and  a  B-model 
P  =  <Bs,  Fb>,  the  fobiect)  o^reduct  of  P,  denoted  pl^  is  the  A-model  Pla  =  <As,  Fa>  where 
As  =  I  s  G  S}  and  Fa={  o(f)B  \fe  Q}.  The  carrier  sets  and  functions  in  the  model  not  associated 
with  signature  A  sorts  and  operations  are  removed  (forgotten). 

Detinition  B.31.  Given  a  signature  A  =  <S,  Q>,  signature  morphism  a:A-^B  and  a  Mod(B)  arrow 
^:pi->P2  the  (arrow)  o=-reduct  of  /i,  denoted  h\c  is  the  Mod(A)  arrow  /?|ct‘Pi|ct“^P2|o  where  the  A|<y  S- 
homomorphism  is  the  family  of  functions  in  h  restricted  to  the  sorts  in  the  signature  of  A,  i.e.  h\^  =  {/Jct(s)  I  s 
€  5o/'to(A)},  and  Pil^  and  P2IC  are  the  (object)  a-reducts  Piand  P2. 

For  every  signature  A,  there  is  a  category  of  E-models,  Mod(A).  For  a  signature  morphism 
cr:A— >B,  how  are  the  model  categories  Mod(A)  and  Mod(B)  related?  There  is  a  functor  that  maps  each 
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M?J(B>object  to  its  o-reduct  object  in  Mod(A)  and  each  Mod(B)-a.now  to  its  o-reduct  arrow  in  Mod(A), 
see  Figure  B-5. 


Figure  B-5.  Each  S  and  S-morphism  in  Sign  has  an  associated  model  category  and  functor 

Proposition  B  J2.  Given  a  signature  morphism  ct:A^B,  the  (functor)  cr-reduct  from  Mod(B)  to  Mod(A), 
Mod(B)\„  :Mod(B)-^Mod(A),  maps  each  Mod(B)-oh}ect  P  to  its  a-reduct  object,  P|„,  in  Mod(A)  and  each 
Mod(B)-anow  h:  Pi  ->^2  to  the  Mod(A)-airaw  /i|<,:Pi|o-^p2l<7- 

Proof: 

Preservation  of  Identity  Arrows:  Let  idp  be  the  identity  arrow  for  P  €  Objects(M«f(B)).  The  identity  arrow 
of  the  Mod(A)  object  p|„  requires  a  family  h  of  sort-indexed  functions  {As:As->Bs  |  s  e  S}  for  each  of  its 
carrier  sets  fliat  maps  the  elements  to  themselves.  The  Mod(B)-vxto'w  idp  has  that  property  for  the  earner 
sets  associated  with  the  sorts  in  iSorts(B).  The  Mod(yf)-arrow(idp|o)  does  as  well  because 
Sorts{A)  c  Sorts(B)  and  a-reductArrow(idp)  function  restricts  the  carrier  set  identity  functions  of  idp  to  those 
over  die  carrier  sets  associated  with  the  sorts  in  Sorts{A),  i.e.  o^redMctAirow(idp)  =  idpio  =  id  a-reduclo^^^^  ■ 

Preservation  of  Arrow  Composition:  Let /Pi^p2  and  g:P2-^P3  be  elements  of  An:ows(Mod(B))  where/ 
and  g  are  S-homomorphisms.  (Sets  of  functions  {/ 1  s  €  S}  and  {  gs  I  s  c  S}  that  map  carrier  set  elements 
in  a  way  that  is  compatible  with  the  model  functions.)  The  function  cp-reductAirm/ig  <>  f)  takes  a  Mod(B) 
S-homomorphism  (g  » /);  Pi  ->  P3  to  a  Mod(A)  S-homomorphism  (g  ®/)|c:Pi|o  p3|<j  by  first  composing 

the  indexed  carrier  set  functions  of/and  g  and  then  restricting  die  composite  set  of  functions  based  on  the 
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(arrow)  c-reduct.  The  composition  o^reductp^Qyf^{g)\^^c  Pala  °  cP‘reductp^Q^{f):^\\a->  p2la  restricts  the 
functions  based  on  the  (arrow)  a-reduct  first  and  then  composes  the  functions,  which  results  in  the  same 
Mod(A)  arrow,  i.e.  o^reduct/^oJ^  ®  /)  "==  o^reductp^oJ^  <>  cp-reductj^^J^f).  [ 

For  every  signature  S  there  may  be  many  E-models,  most  of  which  are  not  desired.  For  example, 
since  signatures  SET  and  LIST  (from  Exan:q)le  B.2  and  Example  B.3)  are  isomorphic  objects  in  Sign, 
Mod(SET)  and  Mod(LIST)  are  the  same  (isomorphic)  collection  of  E-models.  Obviously  only  some  of  the 
E-models  fit  the  notion  of  a  “set”  and  others  the  notion  of  a  “list”.  Selecting  only  those  E-models  that 
satisfy  certain  E-sentences  is  one  way  to  eliminate  unwanted  algebras. 

B.2.5  Specification  models 

Specifications  contain  axioms  that  are  logical  sentences  over  the  signature.  Those  logical 
sentences  must  be  true  of  a  model  of  the  specification;  therefore  there  needs  to  be  a  relationship  between 
E-models  and  E-sentences.  The  relationship  must  be  sound  in  that  if  the  axioms  of  a  specification  entail 
additional  E-sentences  then  so  will  all  models  of  that  specification. 

Deflnition  B33.  Satisfaction  is  a  relation  between  a  E-model  and  a  E-sentence,  wntten  M  N=£  a,  that  is 
used  when  E-sentence  a  is  true  for  model  M.  The  relationship  between  entailment,  and  satisfaction, 

1=2:,  is  defined  as  follows:  if  M  1=2:  a  for  all  a  €  F  and  T  1-2:  P  then  M  \=z  p. 

The  satisfaction  relation  is  used  to  identify  the  E-models  that  satisfy  the  properties  described  by 
the  axioms  of  a  given  specification  over  signature  E. 

Definition  B.34.  A  specification  model  of  specification  <E,  Ax>  is  a  signature  model,  M  g  Mod(E),  where 
M  satisfies  all  axioms,  Ax,  of  the  specification,  i.e.  M  ^=2:  a  for  all  a  g  Ax. 

The  collection  of  models  associated  with  a  specification  A  is  denoted  Mod(A).  By  definition,  the 
collections  of  all  models  of  a  specification  A  is  a  subset  of  the  models  of  the  signature  of  A, 

Mod(A)  c  Mo6{Signature{A)). 

Proposition  B.35.  If  M  g  Mod(A)  and  a  is  a  theorem  of  specification  A  then  M  Nsignature(A) 

Proof:  Immediate  from  Definition  B.33  and  Definition  B.34. 
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Example  B.36.  Given  the  specification  Bool  in  Figure  B-6,  Mod(Bool)  is  the  set  of  all  Bool  signature 
models  that  are  isomorphic  to  BOOLstandani  (Example  B.21),  i.e.  Mod(Bool)  =  {std  |  std  =  BOOLstandard}- 
The  first  axiom  in  specification  Bool,  “True  ^  False”,  eliminates  the  BOOLpmai  model  (Example  B.22) 
as  well  as  any  other  models  that  have  the  same  carrier  set  values  for  the  constant  functions  True  and  False. 
The  last  axiom,  “b  =  True  OR  b  =  False”,  eliminates  all  models  where  there  are  more  than  two 
elements  in  the  Bool  carrier  set.  The  middle  two  axioms  fully  define  the  functionality  of  the  Not  function 
and  eliminate  any  models  that  don’t  have  that  functionality.  Thus  the  axioms  constrain  models  of  the 
specification  Bool  to  have  two  elements  in  the  single  carrier  set  Bool,  with  True  ^  False  and  the  fimction 
Not  defined  in  the  usual  way.  The  theorem  “Not  (Not  (b)  )  =  b”  can  be  proven  from  the  last  three 
axioms  and  therefore  by  Proposition  B.35,  all  specification  models  will  satisfy  that  dieorem  because  they 
satisfy  flie  last  three  axioms. 

Spec  Bool  is 
sort  Bool 
op  True;  ->  Bool 
op  False:  ->  Bool 
op  Not:  Bool  “>  Bool 

Forall  b:Bool 
Ax  True  False 
Ax  Not (True)  =  False 
Ax  Not (False)  =  True 
Ax  b  =  True  OR  b  =  False 

Theorem  Not (Not (b) )  =  b 

end  -  spec _ _ _ _ 

Figure  B-6.  Simple  specification  for  Bool 

Axioms  characterize  the  sorts  and  operations  of  a  specification  by  relating  terms  of  the 
specification.  These  axioms  place  two  types  of  constraints  on  the  models  associated  with  a  specification: 
they  constrain  the  elements  of  the  carrier  sets  and  they  constrain  the  input/output  relation  of  the  functions. 

There  are  two  ways  that  axioms  place  restrictions  on  carrier  set  elements.  One  way  enumerates 
them  to  specific  terms  such  as  axiom  “V  b:Bool  |  b  =  True  or  b  =  false.”  The  Bool-terms 
for  which  there  are  (possibly)  distinct  carrier  set  elements  are  individually  listed.  Another  method  is  to 
equate  or  “dis”-equate  terms.  The  axiom  “True  ^  False”  means  that  the  carrier  set  elements  that  are 
returned  by  constant  functions  True  and  False  are  not  equal  to  each  other.  It  says  nothing  about  how  many 
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other  carrier  set  elements  there  may  be.  Together,  however,  the  two  axioms  limit  the  carrier  set  of  Bool  to 

exactly  two  elements.  Either  axiom  by  itself  is  not  sufficient  to  characterize  the  carrier  set. 

A  term  can  be  thought  of  as  a  “handle”  for  a  carrier  set  element.  If  no  term  exists  for  a  earner  set 

element,  then  there  is  no  way  to  reference  that  carrier  set  element.  Listing  the  terms  is  practical  for  sorts 

like  Bool  whose  (standard)  carrier  sets  have  a  small  finite  number  of  elements  but  it  is  not  practical  in 

general.  Instead,  an  induction  scheme  is  used  to  describe  the  terms  that  are  carrier  set  elements.  The  axiom 

“V  s:Set  3  t:Set,e;E  |  s  =  Empty  OR  s  =  insert  (e,  t)  ”  implies  that  every  carrier  set 

element  for  sort  Set  must  be  the  constant  Empty  or  must  be  derivable  from  Empty  by  inserting  E’s  into 

Empty.  The  text  “Constructors  {Empty,  Insert}  construct  Set”  in  Figure  B-7  is 

syntactic  sugar  for  a  similar  induction  axiom.  The  last  two  axioms  in  Figure  B-6  can  be  viewed  as  using 

equality  between  terms  to  assert  that  some  of  the  terms  generated  by  the  induction  scheme  are  result  in  the 

same  carrier  set  elements. 

spec  Set  is 
sort  Set ,  E 

op  Empty:  ->  Set 

op  Insert:  E,  Set  ->  Set 
op  In:  E,  Set  ->  Boolean 

Constructors  (Empty,  Insert)  construct  Set 

Forall  s:Set,  e,el,e2:E 
Ax  not (In (e, Empty) ) 

Ax  in  (el , Insert (e2 , s) )  ((el^e2)  v  In(el,s)) 

Ax  Insert (e,s)  =  Insert (e, Insert (e, s) ) 

Ax  Insert (el, Insert (e2,s))  =  Insert (e2, Insert (el, s) ) 
end  -  spec _ _ _ 

Figure  B-7.  Constructor  axiom  for  sort  Set 

B.2.6  Specification  model  homomorphisms 

A  homomorphism  between  models  of  a  specification  SP  in  Mod(SP)  is  defined  in  the  same  manner 
as  a  Z-homomorphism  between  S-models  of  a  signature  Z  is  defined  in  Definition  B.25. 

Definition  B.37.  Given  a  specification  SP  =  <S,  Q,  Ax>  and  two  spec-models  of  SP,  A  =  <As,  Fa>  and  B 
=  <Bs,  Fb>,  a  homomorphism,  h:  A— >B  is  defined  to  be  the  Z-homomorphism  between  the  two  models. 
Proposition  B.38.  Models  of  a  specification  A,  Mod(A),  and  the  Z-homomorphisms  between  them  are  the 
objects  and  arrows  in  a  full  subcategory,  Mod(A),  of  the  category  Mod(Signature(A)), 
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Proof:  Oh}ects(Mod(A))  c  Ohiecis(Mod(Signature(A)))  by  definition.  The  S-homomorphisms  between 
Mod(A)  objects  are  the  full  set  of  arrows  between  those  same  objects  in  Mod(Signature(A))  by  definition. 
Therefore  Mod(A)  is  a  full  subcategory  of  Mod(Signature(A)).  1 

Specification  model  categories  have  reduct  functors  between  them  based  on  the  specification 
morphisms  between  them,  as  depicted  in  Figme  B-8.  The  p-reduct  functor  over  specification  model 
categories  is  a  restriction  in  both  the  domain  and  codomain  categories  of  the  o-reduct  functor  between 
signature  model  categories. 

Proposition  B39.  For  any  specification  morphism  p:A— >B  and  associated  signature  morphism 
CT:Signature(A)->Signature(B)  there  is  a  specification  model  category  reduct  functor, 
p-reduct:  Mod(B)->Mod(A),  which  is  a  restriction  of  the  signature  model  category  reduct  functor, 
a-reduct:  Mod(Signature(B))-^Mod(Signature(A))  where  p-reductobject(P)  ~  CT-reductobject(P)  for  all 
P  e  Oh}ects(Mod(B))  and  p-reductAm>w(A)  =  <T-ieductA„^ow(^)  for  all  h  e  Anows(Mod(B)). 

Proof: 

Domain  RpistrirtioTi:  Mod(B)  is  a  foil  subcategory  of  Mod(Signature(B)).  Thus  foe  signature  model 
category  reduct  functor,  cr-reduct:  Mod(Sign(iture(B))—^Mod(Signature(A)),  can  be  restricted  in  its  domain 
to  operate  only  over  foe  objects  and  arrows  in  Mod(B),  i.e.  Mod(B)—¥Mod(Signature(A)).  One  can  also 
view  fods  as  foe  composition  of  foe  inclusion  function  from  Mod(B)->Mod(Signature(B))  with  foe  signature 
reduct  functor,  a-reduct:  Mod(Signature(B))-^Mod(Signature(A)). 

Codomain  restriction:  Mod(A)  is  a  foil  subcategory  of  Mod(Signature(A)).  By  foe  domain  restriction  above 
we  know  that  for  all  models  M  e  Ohiects(Mod(B))  foe  a-reduct  of  M,  Mj^,  is  inMod(Signature(A)).  Is  foe 
Ml,,  also  in  Mod(A),  i.e.  does  M|„  l=signature(A) «  for  all  a  €  Axioms(A)?  We  know  that  for  all  models 
M  e  Ohiects(Mod(B)),  M  t=signature(B)  P(a)  for  all  a  e  Axioms(A)  where  p  is  an  axiom  translation  function 
as  Axioms(B)  l-signatiire(B)  p(a)  and  Definition  B.33  ensures  foat  theorems  of  a  specification  are  satisfied  by 
models  of  a  specification.  A  model  M|a  may  have  fewer  carrier  sets  and  functions  foan  model  M;  however, 
foe  additional  carrier  sets  and  functions  in  M  do  not  change  foe  properties  of  foe  existing  carrier  sets  and 
functions.  Since  foe  axioms  of  A  are  over  foe  reduced  signature  of  M|a.  t=sigiiatiire(A)  a  for  all  a  e 
Axioms(A). 
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Figure  B-8.  Specification  morphisms  induce  reduct  functors 


The  existence  of  a  specification  model  category  reduct  functor,  p-reduct,  associated  with  each 
specification  morphism  p:A— >B,  proves  that  all  models  of  the  codomain  (target)  of  specification  morphism 
p  can  be  viewed  as  models  of  the  domain  (source)  of  p  after  removing  the  extra  earner  sets  and  functions. 
Therefore,  for  a  given  specification  morphism  p:A->B,  all  specification  models  of  B  are  also  (after  being 
p-reducted)  specification  models  of  A.  It  is  this  property  that  enables  a  specification  morphism  to  be 
viewed  as  a  design  refinement  since  any  implementation  of  the  target  specification  is  automatically  an 
implementation  of  the  source  specification,  but  the  reverse  is  not  necessarily  so. 

Earlier  in  the  appendix  the  claim  was  made  that  a  design  decision,  expressed  as  additional 
properties  in  an  algebraic  specification,  may  reduce  the  number  of  possible  implementations  of  a 
specification.  Since  the  p-reduct  of  morphism  p:A->B,  is  not  necessarily  suqective  on  the  codomain 
restriction,  i.e.  the  f)j^cXoT  Mod(B)\^:Mod(B)--^Mod(A)  is  not  epic,  this  means  that  there  may  be  some 
Mod(A)  models  that  are  not  covered  by  the  models  of  Mod(B).  These  models  have  effectively  been 
eliminated  by  the  design  decisions  that  are  implicit  in  the  morphism  from  A  to  B. 
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Appendix  C.  Specification  Development  and  Refinement 

This  appendix  expands  on  the  concepts  introduced  in  Appendix  B  by  describing  how  requirement 
specifications  can  be  developed  and  refined  into  an  implementation.  Although  the  presentation  and  the 
proofs  are  original,  the  material  has  been  published  elsewhere. 

A  formal  software  development  system  fliat  relies  on  algebraic  specifications  for  requirements 
must  have  an  approach  for  developing  and  refining  large  specifications.  A  specification  can  be  developed 
by  listing  its  sorts,  operations  and  axioms,  but  it  is  difficult  to  specify  large  problems  in  such  a  monolithic 
fashion.  A  requirement  specification  can  be  refined  (or  at  least  its  refinement  indicated)  by  means  of  a 
specification  morphism,  but  it  is  difficult  to  develop  large,  monolithic  specification  morphisms  and  target 
specifications  for  large  requirement  specifications. 

The  difficulty  of  developing  and  refining  large  specifications  arises  because  one  is  trying  to 
accomplish  too  much  with  each  specification  and  each  refinement.  Breaking  the  problem  into  smaller 
pieces,  developing  specifications  for  them  independently,  and  then  combining  the  smaller  specifications  so 
that  they  specify  the  problem  as  a  whole  is  one  method  of  developing  and  refining  large  specifications. 
Large  monolithic  refinements  can  be  dealt  with  by  developing  many  smaller  refinements  for  the  smaller 
specifications  (and  doing  less  with  each  refinement)  and  then  combining  them  in  such  a  way  that  they 
refine  the  problem  as  a  whole. 

It  is  important  that  specification  development  methods  be  consistent  with  specification  refinement 
methods.  The  way  that  specifications  are  extended  and  combined  needs  to  be  consistent  and  compatible 
with  the  way  that  refinements  are  extended  and  combined.  For  example,  individual  refinements  of 
component  specifications  should  aggregate  to  form  a  refinement  of  the  aggregation  of  the  component 
specifications. 

This  appendix  is  structured  as  follows.  Section  C.l  describes  how  an  algebraic  specification  can 
be  developed  as  a  translation  of  an  existing  specification,  or  as  an  extension,  conservative  extension,  or 
definitional  extension  of  an  existing  specification.  It  also  describes  how  models  and  model  classes  relate  to 
and  are  related  by  these  constructions.  Section  C.2  describes  how  large  “stmctured”  specifications  can  be 
built  as  an  aggregate  of  oflier  specifications  using  a  colimit  construction.  Section  C.3  describes  the  primary 
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specification  refinement  mechanism,  the  interpretation,  and  how  interpretations  can  be  extended  and 
composed.  Section  C.4  describes  how  refinements  of  component  specifications  can  be  combined  to  form  a 
refinement  of  an  aggregate  specification. 

C 1  Properties  of  Specification  Morphisms 

In  this  section  we  describe  some  of  the  additional  restrictions  that  can  be  placed  on  specification 
morphisms  and  examine  the  effects  they  have  on  the  models  associated  with  the  source  and  target 
specifications  of  the  morphism. 

C.  1 . 1  Specification  translation 

The  simplest  manipulation  of  a  specification  is  a  signature  translation.  A  signature  translation 
enables  one  to  change  the  sort  and  operation  names.  As  long  as  the  names  remain  distinct  after  translation, 
the  class  of  models  associated  with  a  specification  does  not  change. 

Definition  C.l.  Specification  B  is  a  translation  of  specification  A  if  there  exists  an  epimorphism  a:A“>B 
and  Axioms^B)  =  {o‘(a)  |  a  e  Axioms{k)},  where  Sen/^o^{d)  is  a  function  that  translates  A-sentences 
to  B-sentences.  The  epimorphism  is  also  called  a  translation.  If  the  translation  is  an  isomorphism  we  refer 
to  it  as  a  conservative  translation. 

The  name  translation  is  overloaded  in  that  both  the  translation  morphism  and  the  codomain 

(target)  of  the  translation  morphism  are  called  translations.  A  translation  (morphism  and  target)  can  be 

indicated  by  the  code  in  Figure  C-l. 

Spec  List  is 
sort  List,  E 

op  Empty:  ->  List 

op  Append:  E,  List  ->  List 
op  In:  E,  List  “>  Boolean 

Constructors  {Empty,  Append}  Construct  List 
Forall  s, si, s2 :List,  e, el, e2 , e3 , e4 :E 
Ax  Not (in (e, Empty) ) 

Ax  in (el, Append (e2, s) )  =>  {el=e2  v  in(el,s)) 

Ax  (Insert  (el,  si)  =  Insert  (e2 ,  s2) )  <=>  (el=e2  a  sl=s2) 

Ax  (Insert (el, Insert (e2 , s) )  =  Insert (e3 , Insert (e4 , s) )  o  (el=e3  a  e2=e4) 
end- spec 

Spec  Queue  is 

translate  List  by  (List  Queue,  Append  Enqueue} _ 

Figure  C-l.  Specification  translation 
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In  Figure  C-1,  specification  Queue  is  the  translation  of  specification  List  by  the  signature 
morphism  {List-^Queue,  Append— >Enqueue} .  (Specification  Queue  contains  the  sorts,  operations  and 
axioms  of  specification  List  translated  so  that  the  sort  List  is  now  sort  Queue  and  the  operation  Append  is 
now  operation  Enqueue.)  There  is  an  obvious  isomorphism  between  specifications  List  and  Queue,  thus 
there  is  a  conservative  translation  between  the  specifications.  Conservative  translations  have  no  effect  on 
the  meaning  of  a  specification  in  terms  of  its  models;  it  is  a  siiriple  renaming  of  the  sorts  and  operations. 

Thus  the  class  of  models  associated  with  the  source  specification  of  a  conservative  translation  is  identical  to 
the  class  of  models  associated  with  the  target  specification. 

A  non-conservative  translation  (epimorphism  only)  could  translate  two  distinct  sorts  or  operations 
in  the  source  specification  to  the  same  sort  or  operation  in  the  target  specification.  A  non-conservative 
translation  can  be  viewed  as  a  design  decision  that  reduces  the  class  of  models  by  forcing  some  earner  sets 
or  functions  of  all  models  to  be  identical  where  before  they  could  be  different  from  each  other. 

Proposition  C.2,  Translations  and  conservative  translations  are  closed  under  composition.  Therefore  if 
/ :A-^B  and  g;B-^C  are  (conservative)  translation  morphisms  then  their  composition,  g  o/  is  a 
(conservative)  translation  morphism. 

A  — t — ►B — t— :C  A  — Ct— >B  — ct-3>C 

t  ct 

Proof:  Epimorphisms  and  isomorphisms  are  closed  under  composition  in  any  category  [AHS90].  □ 

C.  1 .2  Specification  extension 

An  extension  starts  with  an  existing  specification  as  a  base  and  then  adds  to  it  additional  sorts, 
operations  and/or  axioms.  The  same  base  specification  could  be  extended  in  many  different  ways  to  form 
many  different  extended  specifications.  A  specification  extension  is  somewhat  analogous  to  the  #include 
macro  in  C,  or  like  the  “with”  statement  in  Ada. 

Definition  C3,  Specification  B  is  an  extension  of  specification  A  iff  there  exists  a  monomorphism 
a:A-^B.  The  monomorphism  is  also  referred  to  as  an  extension. 

The  usual  method  for  constructing  an  extension  involves  literally  extending  a  specification  by 
adding  more  sorts,  operations,  and/or  axioms  to  a  specification  to  create  a  new  specification,  as  is  done  in 
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Figure  C-2.  The  semantics  of  the  import  statement  are  to  import  “textually”  the  sorts,  operations  and 
axioms  of  one  specification  into  another.  When  extensions  are  created  in  this  fashion  the  monomorphism  is 
trivial  to  prove  as  each  sort,  op,  and  axiom  is  imported  into  the  extended  specification.  Note,  however,  that 
the  definition  for  an  extension  does  not  require  it  to  be  built  this  way,  or  to  have  the  same  sort  and 
operation  names  or  the  same  (translated)  axioms  as  the  specification  being  extended. 

Example  C.4.  A  specification  extension  (and  an  extension  morphism)  can  be  indicated  by  the  code  in 
Figure  C-2.  Note  that  the  axiom  “Not  (Insert  (e,  s)  =  Insert  (e.  Insert  (e,  s) ))”  expresses  a 
property  that  is  not  typically  associated  with  sets,  hence  the  name  given  to  the  specification.  The  text 
“Import  set”  means  the  sorts,  operations  and  axioms  of  specification  Set  are  textually  imported  into 
specification  Set-No-Longer.  By  constmction,  an  extension  morphism  exists  between  the  Set  and 
Set-No-Longer  specifications,  i.e.  Set  -e-^  Set-No-Longer.  The  extension  morphism  is  called  an  import 
morphism  for  obvious  reasons,  i.e.  import-’morphism:SQt-^  Set-'No-LongQT.  The  Set-No-Longer 
specification  is  referred  to  as  an  extension  of  the  Set  specification.  Note  also  that  the  sorts  Junk, 

More- Junk  and  the  operation  GIGO  have  no  axioms  describing  their  properties  and  are  completely  arbitrary 
extensions. 

Spec  Set-no-Longer  is 

Import  Set 

Sort  Junk,  More -Junk 

Op  GIGO:  Junk,  Junk  ->  More- Junk 

Foral 1  s : Set ,  e : E 

Ax  Not (Insert (e, s)  =  Insert (e, Insert (e, s) ) ) 
end  spec  _ _ 

Figure  C-2.  Extending  a  specification 

Example  C.5.  A  specification  for  a  linear  order  can  be  extended  to  be  either  a  discrete  linear  order  or  a 
dense  linear  order.  The  example  in  Figure  C-3  comes  from  Chapter  4  of  [Dim98].  Note  that  there  is  no 
morphism  between  the  DiLO  and  DeLO  specifications  even  though  both  specifications  have  extension 
(import)  moiphisms  to  them  from  specification  LO. 

If  a  morphism  is  viewed  as  a  refinement  mechanism,  an  extension  can  be  viewed  as  a  stricter  form 
of  refinement  where  all  source  operations  and  sorts  are  refined  into  separate  target  operations  and 
refinements.  An  extension  morphism  preserves  the  structure  of  the  source  specification,  in  terms  of  the 
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number  of  original  sorts  and  operations,  by  not  allowing  them  to  be  “collapsed”  in  the  target  specification. 
Thus  all  implementations  of  the  target  specification  have  separate  and  distinct  earner  sets  and  functions  for 


the  sorts  and  operations  that  originate  in  the  source  specification. 


spec  Di“LO  --  Discrete  Linear  Order 

import  LO 
Forall  x:E 

ax  3  y:E  (V  w:E  { (x  <  y)  a  Not  (  (x  <  w)  a  (w  <  y) ) ) ) 
end- spec  _ _ 


spec  De-LO  --  Dense  Linear  Order 

import  LO 

Forall  x,y:E 

ax  3  w:E  (x  <  y)  =>  (x  <  w)  a  (w  <  y) 
end- spec _ 

Figure  C-3,  Linear-Order  extended  to  Discrete/Dense-Linear-Order 


C.  1 .3  Factoring  a  specification  morphism 

To  be  a  specification  morphism  there  needs  to  be  a  signature  mapping  from  a  source  specification 
to  a  target  specification  and  die  (translated)  source  axioms  must  be  theorems  of  the  target.  Now  that  there 
is  a  notion  of  the  translation  morphisms  and  the  extension  of  morphisms,  an  arbitrary  specification  can  be 
factored  into  component  morphisms.  A  factored  specification  morphism  separates  the  two  concerns  of 
“signature  mapping”  and  “axioms  as  theorems”  into  two  distinct  simpler  morphisms,  a  translation  part  and 
an  extension  part  (that  does  not  involve  translation).  The  definition  of  a  translated  source  specification  and 
morphism  factorization  makes  some  later  definitions  and  proofs  easier. 

Proposition  C.6.  Every  specification  morphism  has  associated  with  it  a  specification  A^  referred 

to  as  the  translated  source  specification  of  a,  where  a  is  factored  into  a  translation  morphism  a^rA-^A*^ 
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and  a  monomorphism  id-monic:A'’-^B  where  Sorts{A°)  c  Sorts(B),  Operations{A  )  c  Operations(B),  and 
a  =  id-monic  »  i.e.  the  following  diagram  commutes; 


A - 


Proof:  Let  ct:A->B  be  a  specification  morphism  where  cj  =  <CTs,  CTn>.  Let  the  sorts,  operations  and 

axioms  of  A"  be  defined  as  follows: 

5orte(A")  =  {cs(s)  |  s  e  5orte(A)}, 

Operations{A°)  =  {odf)  |/e  Operations{A)},  and 
.4jcmms'(A")  =  {5e«Am)w(o)(a)  I  a  e  ^ioms(A)}. 

Let  morphism  =  <0$,  <Jii>  be  the  same  pair  of  functions  in  terms  of  their  set  mappings  as  the 

specification  morphism  ct  except  that  die  codomain  object  is  A”  instead  of  B.  By  construction,  a  is  a 

translation  morphism,  (t^:A— ^A".  Also  by  construction,  Operations{A’’)  c  OperationsiBi), 

5ortt(A")  c  Sorts(B),  dierefore  id-monic: A’’ is  the  identity  mapping  between  sorts  and  operations  (with 

B  as  the  codomain  object  instead  of  A'^.  Thus,  id-monic  is  a  signature  monomorphism.  Id-monic  is  also  a 

specification  motphisrri  as  by  I-  -translation  Axioms!^)  Hb  ct  for  all  a  e  Axioms{A^)  since  that  was  the 

case  for  a  €  Axioms(A).  Finally,  the  diagram  commutes  as 

CTs(s)  =  fs(cr^s(s))  and 

arj(/)  =  iVi(oV/)) 

for  all  s  €  Sorte(A)  and  all /  e  Operations{A).  Q 

Proposition  C.7.  An  extension  a: A-»B  can  be  factored  into  a  conservative  translation  morphism 

>A”  and  an  extension  id-monic:  A"  — >  B  where  A”  is  isomorphic  to  A  (and  Sorts(A!^  c  5orfs(B)  and 
Operations{A’’)  c  Operations(B)). 

Proof:  The  translation  is  an  epimorphism  by  construction.  Since  an  extension  is  a  monomorphism,  the 
translation  is  also  a  monomorphism  by  construction.  Therefore  is  an  isomorphism,  a  conservative 

translation,  and  A"  =  A.  ' 

Notation:  For  any  extension  (t:A->B,  the  sorts  of  specification  B  that  are  in  the  translated  source 
specification  A"  are  referred  to  as  die  original  sorts,  and  they  originate  in  specification  A.  The  sorts  in 
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Sorts(B)  -  SortsiA"")  are  referred  to  as  the  extended  sorts,  and  they  originate  in  specification  B.  The  same 
nomenclature  applies  to  original  and  extended  operations.  In  Figure  C-2  the  extended  sorts  are  Junk  and 
More- Junk  and  the  extended  operation  is  GIGO. 

There  are  several  types  of  specification  extensions  that  have  special  properties  and  special 
meaning  when  related  to  software  requirement  and  design  artifacts.  Two  of  the  most  important  are 
conservative  extensions  and  definitional  extensions. 

C.  1 .4  Conservative  extension 

A  conservative  extension  is  an  extension  that  adds  to,  but  (in  one  sense)  does  not  modify  what 
already  exists  in  the  original  specification.  A  conservative  extension  g;A— is  a  morphism  where  the 
underlying  entailment  relation  over  A-sentences  is  not  altered  in  specification  B.  Thus  the  meaning  of  any 
sentence  over  the  original  signature  of  a  specification  is  unchanged  in  terms  of  its  truth  or  falsehood  under 
entailment  in  any  conservative  extension  of  a  specification. 

Definition  C.8,  A  moiphism  a:  A->B  is  a  conservative  extension  iff  a  is  an  extension  morphism  and 
Axioms{B)  he  a  iff  Axioms{A'')  I-a  «  for  all  a  e  A^-sentences  where  A^is  the  translated  source  spec  of  a. 

For  any  specification  morphism,  cs,  we  have  proven  that  all  models  of  the  target  specification  can 
be  reduced  by  the  c-reduct  functor  to  become  models  of  the  source  specification.  However,  if  cr  is  also  a 
conservative  extension,  the  converse  is  also  true.  If  there  exist  models  of  the  target  specification  at  all,  then 
any  model  of  the  source  specification  can  be  extended  (possibly  in  many  ways)  to  become  a  model  of  the 
target  specification. 

Example  C.9.  A  specification  for  a  discrete  linear  order  can  be  extended  in  a  conservative  fashion  so  that 
it  has  a  non-decreasing  function,  ‘\ip”.  (Function  “up”  may  increase  the  value  given  it  or  return  the  same 
value.)  Any  model  of  specification  Di-LO  can  be  extended  with  a  function  “up”  that  is  a  model  of 
specification  Di-LO-Up.  This  example  comes  from  Chapter  4  of  [Dim98]. 

spec  Di-LO-Up 
import  Di-LO 

op  up:  E  ->  E 

forall  x,y:E 

ax  (x  <  y)  =>  X  <  up(y) 

end- spec  _ _ 
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One  way  to  ensure  that  an  extension  is  conservative  is  to  extend  a  specification  with  sorts, 

operations  and  axioms  that  make  no  reference  to  the  original  sorts  and  operations.  This  is  an  unreasonable 

restriction  as  in  many  cases  one  extends  a  specification  by  building  upon  the  existing  sorts  and  operations 

of  the  original  specification  as  was  done  in  Example  C.IO.  Unfortunately  there  is  no  simple  syntactic 

guarantee  that  a  new  axiom  that  references  the  original  sorts  and  operations  does  not  alter  the  meaning  of 

the  original  sorts  and  operations.  One  can,  however,  use  the  following  syntax  to  indicate  that  one  intends  to 

extend  a  specification  conservatively: 

Spec  Set-of -value-pairs  is 
Protect  Set 

Sort  value 

Op  Left :  E  ^  value 

Op  Right:  E  value 

end- spec _ 

In  the  example  above,  the  Set  specification  has  been  conservatively  extended  (as  indicated  by  the 
text  “Protect  Set”)  with  operations  that  return  a  value  given  an  element  of  sort  E.  The  new  sort  and 
operations  are  not  defined  with  axioms  and  they  do  not  affect  the  entailment  relation  over  the  sentences  of 
the  original  Set  specification.  Thus,  there  is  a  conservative  extension  morphism  between  the  specifications, 
i.e.  Set  -c->  Set-of-value-pairs. 

Conservative  extensions  can  be  related  to  programming  in  a  programming  language.  When 
programming  with  a  language  such  as  Ada  or  FORTRAN,  the  built  in  data  t3fpes  and  subprograms  can  be 
augmented  with  other  data  types  and  subprograms.  One  can  combine  two  or  more  collections  of  unrelated 
data  types  and  subprograms  together.  One  can  also  create  structured  data  types  or  subtypes  from  existing 
data  types  and  combine  subprograms  with  control  structures  to  create  more  powerful  subprograms. 
Conservative  extensions  and  programming  extensions  differ  in  that  with  (normal)  programming  extensions 
a  programmer  does  not  have  to  worry  that  the  use  of  a  data  type  or  subprogram  will  indelibly  change  its 
meaning.  It  simply  isn’t  possible  to  do  this  when  using  a  programming  language  constmct.  One  can,  using 
syntactically  different  methods,  modify  or  overwrite  existing  programming  language  concepts,  such  as 
redefining  a  method  in  object-oriented  programming,  but  in  most  programming  languages  it  is  simple  to 
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syntactically  differentiate  when  one  is  using  a  type  or  subprogram  or  redefining  (modifying  or  overwriting) 
it  and  programmers  do  not  confuse  the  two. 

For  extensions  of  specifications,  however,  this  stability  of  meaning  is  not  given.  The  axioms  of  a 
specification  logically  relate  the  operations  referenced  within  it  and  do  not  differentiate  which  operations 
should  be  fixed  in  meaning  and  which  ones  are  being  defined.  Unlike  a  programmer,  a  specifier  needs  to 
prove  that  the  extensions  that  are  intended  to  be  conservative  do  not  change  the  underlying  meaning  of  any 
of  the  existing  sorts  and  operations.  For  specifications  there  is  no  simple  syntactic  check  or  guarantee  that 
extensions  preserve  meaning  as  there  is  with  programming  languages. 

Example  C.IO.  A  specification  for  a  discrete  linear  order  can  be  extended  in  a  seemingly  conservative 

fashion  so  that  it  has  a  maximum  value  function. 

Spec  LO-Max 
Protect  LO 

Op  Max:  ->  E 

forall  x;E 

ax  X  <  Max  or  X  =  Max 
end-spec _ _ 

Despite  the  stated  intentions  of  the  syntax,  “Protect  LO”,  the  extension  is  not  conservative. 

The  extended  axiom  has  a  “side  effect”  in  that  it  implies  that  there  is  an  upper  bound  in  the  discrete  linear 
order.  This  means  an  axiom  describing  the  property  of  having  an  upper  bound, 

“V  x:E,  3  y:E  |  x  <  y  ^  x  =  y”, 

is  a  theorem  of  specification  LO-Max  but  it  is  not  a  theorem  of  specification  LO.  Since  that  property  can 
be  expressed  entirely  in  terms  of  specification  LO’s  signature,  the  extension  is  not  a  conservative  extension. 

Conservative  extensions  are  important  in  a  software-engineering  environment  in  that  they 
represent  an  “embedding”  of  all  the  models  of  one  specification  in  the  models  of  another  specification.  All 
of  the  models  of  the  specification  being  extended  have  one  or  more  “model  extensions”  that  are  models  of 
the  extended  specification.  For  a  conservative  extension  c:A->B,  all  (abstract)  implementations  of 
specification  B  contain  an  “embedded”  model  of  specification  A  and  unlike  with  a  normal  extension,  all 
models  of  specification  A  are  represented  in  such  a  manner  (the  reduct  is  suqective).  An  arbitrary  (non¬ 
conservative)  morphism  can  be  viewed  as  a  refinement  mechanism  where  some  models  have  been 
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eliminated  in  the  models  associated  with  the  target  specification  (actually  eliminated  in  the  morphism 
reduct  of  the  models  of  the  target  specification).  A  conservative  extension  morphism  can  be  viewed  as  an 
“embedding”  mechanism  as  every  model  can  be  extended  with  additional  carrier  sets  and  operations 
(sometimes  in  many  different  ways)  so  that  it  is  a  model  of  the  target  specification. 


spec  One-Sort  is 
sort  X 
end- spec 

{X^E} 


spec  Set  is 

sort  Set,  E 

op  Empty: 

-  >  Set 

op  Insert:  E, 

Set  ->  Set 

op  In:  E, 

Set  ->  Boolean 

etc.  —  See  Figure  B-7 

end- spec 

Figure  C-4.  Conservative  extension  (parameterization) 


Example  C,ll.  The  morphism  One-Sort  -c->  Set,  depicted  in  Figure  C-4,  is  also  an  example  of  a 
conservative  extension.  Any  model  of  specification  One-Sort  can  be  extended  with  set-like  operations. 
(Any  carrier  set  associated  with  sort  X  in  specification  One- Sort  can  be  extended  with  a  carrier  set  for  the 
sort  Set  where  the  functions  Empty,  Insert,  and  In  operate  as  one  would  expect  according  to  the  axioms  of 
specification  Set.)  This  corresponds  to  the  intuitive  notion  that  given  any  collection  of  elements,  one  can 
form  a  set  of  some  subset  of  those  elements. 

A  conservative  extension  morphism  is  important  to  the  concept  of  parameterization  as  Example 
C.l  1  demonstrates.  Current  parameterization  research  is  presented  in  Section  2.3  and  Appendix  E.  This 
dissertations  contributions  to  parameterization  is  the  focus  of  Section  3.5,  Section  4.2  and  Chapter  5,  where 
conservative  extensions  play  an  important  part. 

C.  1 .5  Definitional  extension 

A  definitional  extension  is  a  conservative  extension  where  the  added  sorts  and  operations  are  fully 
characterized  over  the  original  sorts  and  operations,  A  definitional  extension  cannot  merely  extend  a 
specification  with  unrelated  sorts  and  operations  as  is  possible  with  a  conservative  extension.  The  new 
sorts  and  operations  in  a  definitional  extension  must  be  defined  and  fully  characterized  (directly  or 
indirectly)  over  the  sorts  and  operations  of  the  specification  being  extended. 
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DeHnition  C.12.  A  morphism  a:A->B  is  a  definitional  extension  (d-morphism)  iff  it  is  a  conservative 
extension  morphism  and  all  extended  sorts  are  constructed  sorts  and  all  extended  operations  are  defined  to 
be  total  and  functional. 

If  a:A->B  is  a  definitional  extension  then  models  of  specification  A  can  be  uniquely  extended  so 
that  they  are  models  of  specification  B.  Because  of  the  additional  constraints  put  on  by  definitional 
extensions  the  extension  that  takes  a  particular  model  of  specification  A  to  a  model  of  specification  B  is 
unique  [BGG94]. 

Definition  C.13.  Total  and  functional  operations  are  defined  as  follows: 

if  A  is  a  specification  and /is  an  operation  with  rank  Si,  S25  ...  Sn  s  then/is  total  and  functional  iff  the 
following  axioms  are  theorems  of  specification  A: 

V  ai-Si,  a2:S2, ...,  otn:Sn,  ay:s  I  /(ai,  a2, ...,  an)  =y 

V  ai:Si,  a2:S2,  an:Sn, yid^2:S,  (/(tti,  a2,  ...,  ttn)  =^1  A  /(ai,  a2,  ...,  ttn)  =^2)  =>  (yi  ==^2) 

For  models  of  specification  A,  the  function  associated  with  a  total  and  functional  operation/is 

guaranteed  to  return  a  unique  output  element  of  the  output-sort  carrier-set  given  input  elements  of  the 
appropriate  carrier-sets.  Once  the  carrier-sets  are  fixed  there  can  only  be  one  function  (in  the  sense  of  an 
abstract  input/output  relation)  associated  with  the  operation  f  as  that  function  is  defined  to  be  unique  by  the 
axioms  of  specification  A. 

In  a  definitional  extension,  the  axioms  used  to  fully  indicate  the  total  and  functional  nature  of  an 
extended  operation  must,  by  definition,  be  conservative.  Since  the  axiom’s  sole  purpose  is  to  fully  define 
an  operation,  and  they  do  not  affect  the  meaning  of  any  other  sort  or  operation,  they  can  be  linked  to  that 
operation  using  the  syntax  indicated  in  Figure  C-5,  which  is  slight  variation  of  the  Specware  language 
[SLM98]: 

The  text  “define  f  by”  in  Figure  C-5  can  be  viewed  as  a  syntactic  sugar  replacement  for 
additional  axioms  concerning  operation /that  confirm  that  operation/is  functional  and  total.  For  example, 
if  the  rank  of/is/  X^Y  then  the  following  axioms  insure  that /is  functional  and  total: 

V  jc:X,  V  j;2:Y,/(x)  =yl  a  f{x)^2  =>  yl^2  V  x:X,  3  y:Y  \f{xyy 

Axioms  such  as  these  need  to  be  theorems  of  the  specification  for  each  defined  operation  in  order  for  the 
operation  to  be  proven  both  functional  and  total. 
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spec  Augmented- Li St  is 
Protect  List 

Op  No-Dupes:  List  Boolean 

Op  Add- if -new:  E,  List  — >  List 
Op  Count:  E,  List  Nat 

Op  Perm:  List,  List  Boolean 

Forall  e,el,e2:E,  1,  ll,12:List 

define  No -Dupes  by 
Ax  No -Dupes (Empty) 

Ax  No-Dupes  (Insert  (e,  1) )  =  (No-Dupes(l)  a  not  (In (e,  1) ) ) 
define  Add- if -new  by 

Ax  Add-if-new(e,  Empty)  =  Append(e,  Empty) 

Ax  Add-if-new(e,  1)  =  if  in(e,  l)then  1 

else  Append (e,  1) 

define  Count  by 

Ax  Count (e,  Empty)  =0 

Ax  Count (el, Append (e2,  1))  =  if  el=e2  then  1  +  Count (el, 1) 

else  Count (el, 1) 

define  Perm  by 

Ax  Perm(ll,12)  =  (count (e, 11)  =  count (e, 12)) 

end- spec  _ _ _ _ _ _ _ _ 

Figure  C-5.  Total  and  functional  definitions 

For  specification  Augmented-List,  the  operations  No-dupes,  Add-if-new,  and  Count  are  defined 
over  the  original  operations,  the  axioms  in  the  definition  clause  are  conservative  (they  do  not  change  the 
entailment  relation  over  flie  original  signature),  and  the  axioms  insure  that  these  operations  are  functional 
and  total.  Note  that  the  operation  Perm  is  defined  using  the  newly  defined  Count  operation  and  therefore  it 
is  indirectly  defined  over  the  original  specification.  Because  all  extended  operations  in  Figure  C-5  are 
defined  to  be  functional  and  total,  Augmented-List  is  a  definitional  extension  of  List,  i.e. 


List-d-»Augmented-List. 

All  extended  sorts  that  are  definitional  extensions  must  be  constructed  from  the  existing  sorts. 
Examples  of  this  are  subsorts  ( s  |/),  quotient  sorts  (  s  //),  product  sorts(  s,,  S2, ...),  and  coproduct  sorts 
(s,  +  S2+...),[SLM98]. 

Definition  C.14.  Given  a  set,  Sorts{A),  of  existing  sorts,  a  collection  of  Constructed  sorts,  CS,  is  defined 
inductively  as  follows: 

■  All  original  sorts  are  constructed  sorts,  s  e  iSorfs(A)  implies  that  s  6  CS. 
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■  All  subsorts  are  constructed  sorts,  s  e  CS  implies  that  s\f  e  CS  where /rs^boolean  and  a  g  s|/ 
iff  a  G  s  a/ (a).  All  subsorts  have  an  implicit  relaxation  function  that  takes  elements  of  s|/  to 
s,  i.e.  (relax /):  sl/->s. 

■  All  quotient  sorts  are  constructed  sorts,  s  g  CS  implies  that  s//  g  CS  where / :s,S“>boolean  is  an 
equivalence  relation  (reflexive,  transitive,  and  symmetric)  and  a  e  sif  iff  a  is  an  equivalence 
class  induced  on  s  by  /  All  quotient  sorts  have  an  implicit  quotient  function  that  takes  elements 
of  s  to  their  quotient  (equivalence  class)  in  s/f,  i.e.  (quotient /):  s^s/f. 

■  All  product  sorts  are  constructed  sorts.  Si,  S2, . . .  Sq  e  CS  implies  that  (si,  S2, . . .  Sn)  g  CS  where 
(si,  S2, . . .  Sn)  is  the  cross  product  of  sort  values.  All  product  sorts  have  a  family  of  implicit 
projection  functions  that  extract  a  sort  value  from  a  tuple,  i.e.  (project  i):  Si,  S2,  ...  Sn--> 

■  All  coproduct  sorts  are  constructed  sorts.  Si,  S2, . . .  s^  g  CS  implies  that  Si  +  S2  +  . . .  +  Sn  g  CS 
where  +  is  analogous  to  the  disjoint  union  of  sort  values.  All  coproduct  sorts  have  a  family  of 
implicit  embedding  functions  that  embed  a  sort  value  into  a  coproduct, 

i.e.  (embed  i):  Si  ^  Sj  +  S2  +  . . .  +  Sn. 

For  models  of  specification  A,  the  carrier  set  associated  with  a  constructed  sort  s  is  defined  based 
on  the  carrier  sets  associated  with  the  sorts  from  which  it  was  constmcted.  Once  the  carrier-sets  of  the 
defining  sorts  are  fixed  (and  the  defining  functions  are  fully  defined)  there  can  only  be  one  carrier  set 
associated  with  the  constructed  sort  s. 

Constmcted  sorts  are  related  to  programming  language  types  in  the  following  way.  Subsorts  are 
similar  to  subtypes,  product  sorts  are  similar  to  record  types  and  coproduct  sorts  are  similar  to  polymorphic 
types  or  variant  records.  Few  programming  languages  have  a  construct  similar  to  quotient  sorts;  however, 
they  can  be  simulated  by  using  an  equivalence  relation  over  a  given  type  in  place  of  using  the  ‘ (strict 
equality)  operation.  One  can  add  axioms  to  a  specification  to  indicate  that  the  relationships  defined  above 
hold  between  the  original  sorts  and  the  constmcted  sorts,  or  one  can  use  the  sort  axioms  in  Figure  C-6  as 
the  semantic  equivalence  of  those  axioms. 

The  text  “sort  -  axiom  S  =”  in  Figure  C-6  can  be  viewed  as  a  syntactic  sugar  replacement  for 
additional  axioms  that  constrain  the  sort  being  defined  by  relating  it  to  an  existing  sort  and  some  fully 
defined  function(s).  The  sort-axiom  also  serves  as  a  placeholder  for  the  definition  of  the  polymorphic 
access  operations  (such  as  relax,  quotient,  project,  embed  described  in  Definition  C.14).  In  the  example 
above,  the  extended  sorts,  List-2,  SubsortList,  QuotientList,  ProductList,  and  CoproductList  are  all 
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constructed  sorts.  Note  that  ProductList  is  constructed  using  other  constructed  sorts.  Because  the  extended 
sorts  are  all  fully  defined  there  is  a  definitional  extension  morphism  from  specification  Augmented-List  to 
specification  Augmented-List-2, 

Spec  Augmented-List-2  is 
Protect  Augmented-List 

Sort  List-2,  SubsortList,  QuotientList ,  ProductList,  CoproductList 
Sort-axiom  List-2  =  List 

Sort-axiom  SubsortList  =  List [No-Dupes 

Sort-axiom  QuotientList  =  List/Perm 

Sort-Axiom  ProductList  =  List,  QuotientList,  SubsortList 

Sort-Axiom  CoproductList  =  E  +  List 

end- spec _ 

Figure  C-6.  Constructed  sorts 

The  concept  of  the  extension  being  built  using  the  original  specification  carries  over  to  the  models 
of  the  specifications  as  well.  For  a  definitional  extension  a:  A->B  the  a-reduct  functor  from  Mod(B)  to 
Mod(A)  is  epic  and  monic  and  has  an  inverse  functor  that  is  the  unique  extension  taking  models  of  Mod(A) 
to  models  of  Mod(B)  [BGG94].  Each  carrier  set  of  an  extended  sort  of  a  model  in  Mod(B)  is  related  to  the 
carrier  sets  in  some  model  in  Mod(A)  in  some  xmique  way,  i.e.  they  are  related  by  being  the  same  carrier 
set,  a  particular  subset,  quotient  set,  product  of  sets,  or  coproduct  of  sets.  Every  function  associated  with  an 
extended  operation  of  a  model  in  Mod(B)  has  a  fully  defined  meaning  by  Definition  C.13;  thus  for  any 
given  Mod(A)  model  there  is  only  one  function  that  fits  the  defined  meaning  that  is  in  the  associated  model 
in  Mod(B). 

Definitional  extensions  are  important  in  a  software-engineering  environment  in  that  they  represent 
constructing  a  “larger”  model  (one  with  more  carrier  sets  and  functions)  from  an  existing  model  in  a  unique 
way.  For  a  definitional  extension  J:A*-»B,  every  (abstract)  implementation  of  specification  A  has  a  unique 
extension  that  makes  it  an  (abstract)  implementation  of  specification  B.  This  is  unlike  a  conservative 
extension  where  there  may  be  many  such  extensions.  Since  every  model  of  specification  A  has  a  single 
extension  that  makes  it  a  model  of  specification  B,  we  can  view  a  definitional  extension  as  an  (abstract) 
implementation  constmctor.  Given  an  (abstract)  implementation  of  specification  A,  we  can  construct  an 
abstract  implementation  of  specification  B  in  a  single  way.  (There  may  be  more  then  one  way  to  code  the 
implementation  but  their  abstract  functionality  is  identical.)  Thus  while  we  view  a  conservative  extension 
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as  an  implementation  “embedding”  mechanism,  a  definitional  extension  is  an  implementation 
“construction”  mechanism.  Section  C.3,  which  covers  specification  refinement,  has  several  examples  of 
definitional  extensions. 

C.  1 .6  Composition  of  extension  morphisms 

An  extension  ensures  that  the  target  specification  does  not  collapse  any  of  the  distinct  sorts  and 
operations  of  the  source  specification,  A  conservative  extension  represents  an  embedding  or  composition 
of  independent  models.  A  definitional  extension  represents  a  construction  of  implementations.  We  would 
expect  such  properties  to  compose. 

Proposition  C.15,  Extensions,  conservative  extensions  and  definitional  extensions  are  closed  under 
composition,  i.e,  if/ :  A^B  and  g:B->C  are  both  extensions,  conservative  extensions  or  definitional 
extensions  then  their  composition,  g  ©  /  is  an  extension,  conservative  extension  or  definitional  extension 
respectively. 

A - e— — e — >C  A  —  c — ►B  — c - ►€  A. —  d— ►B — d — jC 

e  c  ""  d 

Proof: 

Extensions:  Given  extension  moiphisms / :A->B  and  g:B— >C,  both /and  g  are  monomorphisms,  therefore 
their  composition,  g  ©  /  is  a  monomorphism  (and  hence  an  extension). 

Conservative  Extensions:  Given  conservative  extension  morphisms / : A— >B  and  g:B^C,  their 
composition,  g  ©/  is  an  extension  morphism  by  the  proof  above.  By  /  Axioms(B)  f-B  a  for  each 
a  e  A^-sentences  iff  Axioms(Af )  I-a  where  Af  is  the  translated  source  specification  of/  By  g, 
Axioms(C)  l-c  P  for  each  p  e  B^-sentences  iff  Axioms(B^  Kb  P  where  B^  is  the  translated  source 
specification  of  g.  Thus  by  the  transitivity  and  I — translation  properties  of  entailment  for  g  ®/ 

Axioms(C)  l-cttforeacha  e  A^ ’^-sentences  iff  Axioms(A^‘^)  1-a  ct  where  A^‘-^is  the  translated  source 
specification  of  g  ©/ 

Definitional  Extensions:  Given  definitional  extension  morphisms / :A-^B  and  g:B— >C,  their  composition, 
g  ©  /  is  a  conservative  extension  morphism  by  the  proof  above.  By  /  the  extended  sorts  in  specification  B 
are  constructed  sorts.  By  g,  the  extended  sorts  in  specification  C  are  constructed  sorts.  Therefore  all  sorts 
in  specification  C  that  did  not  originate  in  specification  A  are  constructed  sorts.  Similar  logic  holds  for  the 
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extended  operations  in  specifications  B  and  C.  Since  g  ©  /  is  a  conservative  extension  where  all  extended 
sorts  in  the  codomain  are  constructed  sorts  and  all  extended  operations  in  the  codomain  are  total  and 
functional,  g  o/is  a  definitional  extension.  ^ 

Example  C.16.  Using  the  syntax  for  sort-axioms  and  the  define-by  statement  described  above  for 
definitional  extensions  it  is  easy  to  see  how  d-morphisms  compose  from  a  syntactic  perspective.  The 
definitional  extensions  List-^Augmented-List  and  Augmented-List-^Augmented-List-2  can  be  composed 
such  that  there  is  a  definitional  extension  List-^Augmented-List-2.  The  composite  morphism  (and 
specification)  can  be  represented  by  syntactically  composing  the  extensions. 

C2  Specification  Aggregation 

The  previous  section  described  how  a  larger  specification  can  be  constructed  by  adding  additional 
sorts,  operations  and  axioms  to  an  existing  specification.  In  this  section  an  aggregation  mechanism  is 
described  that  enables  existing  specifications  to  be  combined  to  create  a  larger  stmctured  specification. 

The  specification  is  stmctured  in  that  the  specifications  that  serve  as  components  of  the  larger  specification 
can  be  identified  as  such  and  the  aggregation  mechanism  documents  how  these  component  specifications 
are  combined  to  form  the  larger  specification  and  are  related  to  the  larger  specification. 

Aggregation  enables  many  smaller  specifications  to  be  written  and  then  combined  to  specify  larger 
problems.  When  creating  an  aggregate,  the  aggregate  object  should  be  minimal  in  that  it  should  only 
include  those  properties  (requirements)  that  are  present  in  the  component  specifications.  The  process  for 
creating  an  aggregate  should  not  place  any  additional  constraints  on  the  problem  being  specified  beyond 
those  that  can  be  derived  from  the  components  of  the  aggregate. 

C.2.1  Pushout 

In  the  category  Spec,  a  pushout,  and  the  more  general  colimit,  are  category  constmctions  that 
define  a  minimal  aggregate  object  from  a  collection  of  related  objects.  The  minimal  aggregate 
specification  represents  the  minimal  requirement  specification.  Any  other  aggregate  specification  is 
guaranteed  to  have  more  structure  or  properties  (and  hence  more  requirements)  than  can  be  inferred  from 
the  component  specifications. 
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A  pushout  in  the  category  Spec  has  the  same  structure  as  depicted  in  Figure  A-8.  However,  the 
objects  are  specifications  and  the  arrows  are  specification  morphisms.  Specification  A  represents  the 
signature  and  properties  over  the  signature  that  must  be  present  (after  translation  and  by  entailment)  in  both 
specifications  B 1  and  B2  before  they  can  be  merged. 


Example  C.17.  The  Set  specification  can  be  combined  with  a  specification  for  an  enumerated  type,  Flag, 
to  form  the  specification  Set-of-Flag.  Figure  C-7  provides  a  graphical  depiction  of  the  commuting  pushout 
square.  Note  that  the  purpose  of  the  One-Sort  specification  is  to  indicate  how  the  other  specifications  are  to 
be  related. 


spec  One -sort 
sort  X 
end- spec 


{X-^Flag} 


{X-»E} 


spec  Flag 
sort  Flag 

op  Green:  ->  Flag 
op  Yellow:  ->  Flag 
op  Red:  ->  Flag 

constructors  {Green,  Yellow,  Red}  construct  Flag 
Ax  Green  ^  Yellow 
Ax  Green  ^  Red 
Ax  Yellow  ^  Red 
end- spec 


spec  Set  is 
sort  Set,  E 

op  Empty:  ->  Set 

op  Insert:  E,  Set  ->  Set 
op  In:  E,  Set  ->  Boolean 

constructors  (Empty,  Insert}  construct  Set 
Forall  s:Set,  e,el,e2:E 
Ax  not (In (e, Empty) ) 

Ax  in (el, Insert (e2, s) )  => 

( (el=e2)  V  ln(el, s) ) 

Ax  Insert (e , s )  =  Insert (e , Insert (e , s ) ) 

Ax  Insert (el , Insert (e2, s) )  = 

Insert (e2 , Insert (el, s) ) 

end- spec 


spec  Set-of-Flag  is 
sort  Set,  Flag 
op  Empty:  ->  Set 

op  Insert:  Flag,  Set  ->  Set 
op  In:  Flag,  Set  ->  Boolean 

op  Green:  ->  Flag 
op  Yellow:  ->  Flag 
op  Red;  ->  Flag 

constructors  (Empty,  Insert}  construct  Set 
constructors  (Green,  Yellow,  Red}  construct  Flag 
Forall  s:Set,  e,el,e2:Flag 
Ax  Green  ^  Yellow 
Ax  Green  ^  Red 
Ax  Yellow  ^  Red 
Ax  not (In (e, Empty) ) 

Ax  in(el, Insert (e2, s) )  => 

( (el=e2)  V  In(el,  s) ) 

Ax  Insert (e,s)  =  Insert (e, Insert (e, s) ) 

Ax  Insert (el, Insert (e2 , s) )  = 

Insert {e2, Insert (el, s) ) 

end- spec 


Figure  C-7.  Simple  pushout  example:  Set-of-Flag 


Proposition  C.18.  Given  specification  monomorphisms / :  A^Bl  and  g :  A“^B2  where/  =  <fsyfa>  and 
=  ^gsy  and  assuming  that  the  sets  of  sort  and  operation  names  of  the  three  specifications  are  disjoint, 
the  pushout  specification  C  can  be  constructed  in  the  following  manner: 

Let  specification  SI  be  a  conservative  translation  of  specification  B1  where  the  names  of  the  sorts  and 
operations  of  B1  have  been  translated  to  the  names  of  the  specification  A  sorts  and  operations  as  indicated 
by  the  morphism /  let  the  B1  axioms  be  translated  in  accordance  with  the  new  sort  and  operation 

names 
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i.e.  El  =  <{Sorts(Bl)  -  {fs(a)  I  «  ^  Sorts(A)})  u  Sorts(A), 

{Operations{Bl)  -  \fa^a)  I  «  e  Operations{A)})  u  Operations{AX 

{B1  axioms  translated  from  Bl-sentences  to  sentences  over  the  sort  and  operation  names  above}> 

Let  specification  E2  be  similarly  derived  from  specification  B2, 

i.e.  E2  =  <(Sorts(B2)  -  {gs(a)  I  «  g  Sorts{A)})  u  Sorts{A), 

(Operations(B2)  -  {gn(a)  I  «  e  Operations{A)})  u  Operations{A\ 

{B2  axioms  translated  from  B2-sentences  to  sentences  over  the  sort  and  operation  names  above}> 

Let  the  sorts,  operations  and  axioms  of  the  pushout  specification  C  be  defined  as  follows: 

Sorts(C)  -  Sorts(Ll)  u  Sorts(L2) 

Operations(C)  =  Operations(L\)  u  Operations(L2) 

Axioms(C)  =  Axioms(Ll)  u  Axioms(L2) 

and  the  morphisms  from  B1  and  B2  to  C  be  the  obvious  ones  based  on  the  relationships  between  the  Bx, 

Ex,  and  C  specifications,  i.e.  the  compositions  of  Bl^El— >C  and  B2”^E2— >^C. 

Proof:  In  order  to  prove  the  above  construction  is  valid  we  must  prove  that  it  results  in  a  commuting 
square  where  the  constructed  pushout  specification  has  a  unique  arrow  to  the  terminal  specification  of  any 
other  commuting  square. 

Existence  of  pushout  object:  By  this  method  of  construction,  the  B1  and  B2  specifications  are  translated  to 
El  and  E2  based  on  the  unifying  sort  and  operation  names  in  specification  A  and  the  morphisms  A”>B1 
and  A-^B2.  Essentially  our  constraction  has  created  the  conservative  translation  morphisms  B1->E1  and 
B2“»E2  where  El  and  E2  share  the  signature  of  specification  A.  The  pushout  specification  C  is  merely  a 
union  of  the  sets  of  sorts,  operations,  and  axioms  of  El  and  E2.  The  monomorphisms  El^C  and  E2->C  are 
the  identity  mappings  of  the  sort  and  operation  names  where  the  axioms  are  trivially  proven  to  be  theorems 
of  specification  C.  The  axioms  of  specification  A  do  not  need  to  be  included  in  C  as  they  are  theorems 
(after  translation)  of  specifications  B1  and  B2  and  hence  are  theorems  of  specification  C.  The  composite 
morphisms  A~»B1^C  and  A->B2->C  are  equivalent  by  constmction  as  the  sorts  and  operations  of 
specification  A  are  mapped  (via  El  for  B1  and  via  E2  for  B2)  to  the  same  sorts  and  operations  of 
specification  C,  therefore  the  pushout  square  is  a  commutative  square. 

Existence  of  Arrow:  Assume  that  there  exist  other  C-arrows  /i:B2->D  and y:Bl->D  such  that  that 
j  of=h  o  g.  Let  al:El“^Bl  and  a2:E2^B2  be  the  conservative  translations  where  al=<als,  crln>  and 
a2=<a2s,  a2o>.  The  signature  morphism  from  k:Signature(C)->Signature{D)  is  defined  as  follows:  Let  k 
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be  a  signature  morphism,  k  =  k^  where  I  ®  (or  equivalently  if  s  e  Sorts(A) 

otherwise,  =  As  ®  a2s  ifs  e  Sorts(Z2)  OR  As  =7s  °  alsifs  g  Sorts(Il)}  and  where  kn  is  similarly  defined 
over  the  operations  in  specifications  A,  SI,  and  S2  and  the  operation  mapping  functions  from  those 
specifications  to  specification  D.  By  this  construction  we  know  there  exists  a  signature  morphism  from  C 
to  D.  The  signature  moiphism  Signature(C)“>Signature(D)  is  a  specification  morphism  as  it  is  a  given  that 
the  translated  axioms  in  Axioms{B\)  and  Axioms{Q2)  are  theorems  of  specification  D  and  therefore  the 
axioms  in  Axioms{C)  can  be  similarly  translated  and  proved  as  theorems. 


Figure  C-8.  Diagram  supporting  the  existence  of  arrow  C->D 

Arrow  Completes  a  Commuting  Diaeram:  The  sorts  and  operations  in  specification  C  can  be  split  into  three 
groups,  those  originating  fi:om  specification  A,  those  originating  in  specification  B1  (and  not  A),  and  those 
originating  in  specification  B2  (and  not  A).  In  each  case,  the  mapping  of  these  three  groups  of  sorts  and 
operations  of  specification  C  to  specification  D  is  defined  to  be  the  same  as  the  mapping  of  these  sorts  and 
operations  from  their  non-C  origin.  Thus  by  construction,  the  arrow  completes  a  commuting  diagram. 
Uniqueness  of  Arrow:  Let  m  be  any  other  specification  morphism,  /w:C— >D  for  which  Figure  A-8c  forms  a 
commuting  diagram.  Assume  that  morphism  m  is  a  different  arrow  then  A,  i.e.  ms  ^  As  or  mn  ^  An-  Since 
the  arguments  for  sorts  and  operations  are  identical,  lets  work  with  sorts  only.  If  ms  As  then  there  exists 
an  s  e  Sorts(C)  such  that  ms(s)  ^  As(s).  However,  based  on  our  assumption  for  m  we  know  that  the  overall 
diagram  commutes  for  both  m  and  A,  i.e.  the  arrows  A-^C,  Bl— >C,  and  B2->C  when  composed  with 
arrows  A:C->D  and  m:C->D  form  equivalent  arrow  pairs.  For  the  composed  arrows  to  be  equivalent  and 
there  exist  a  sort  s  e  Sorts(C)  such  that  ms(s)  ^  As(s)  then  s  must  be  a  sort  in  C  that  is  not  mapped  to  by  any 
of  the  morphisms  A->C,  B1->C,  and  B2-^C.  However,  by  construction  we  know  that  this  is  not  the  case. 
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as  all  sorts  in  specification  C  are  mapped  to  by  at  least  one  sort  in  specification  A,  Bl,  or  B2.  Therefore  by 
construction  we  know  there  does  not  exist  an  s  e  Sorts(C)  such  that  ms(s)  ^  ks{s).  By  similar  reasoning  we 
know  fliat  there  does  not  exist  an/G  Operations{C)  such  that  ma{f)  ^  W/)*  By  contradiction,  we 
know  that  our  original  assumption  is  wrong  and  m  =  k.  □ 

Alternative  pushout  construction  methods  use  the  Bl  (or  B2)  sort  and  operation  names  as  the 
xmifying  names.  Unfortunately,  all  of  these  construction  methods  rely  on  the  sort  and  operation  names  of 
the  three  specifications  being  disjoint  and  that  the  specification  morphisms  be  monomorphisms. 

The  construction  method  can  be  extended  to  work  with  name  spaces  that  are  not  disjoint  by  first 
translating  the  specifications  so  the  sort  and  operation  names  are  disjoint.  Disjoint  names  can  be  arbitrarily 
chosen,  or  they  can  be  constructed  by  appending  the  specification  name  (or  some  unique  identifier)  to  all 
the  sort  and  operation  names  of  each  specification,  i.e.  using  the  sort  or  operation  “specification  of  origin” 
to  distinguish  it  from  other  sorts  and  operations. 

To  extend  the  pushout  construction  method  of  Proposition  C.18  to  work  with  non- 
monomorphisms  one  must  be  able  to  indicate  when  the  original  specification  morphisms  (/ and  g)  have 
merged  two  or  more  sorts  (or  operations).  In  the  original  construction  the  specification  Bl  (and  B2)  sort 
and  operation  names  were  translated  to  their  specification  A  names.  However,  with  non-monomorphisms 
there  are  two  (or  more)  possible  Bl  (B2)  names  to  choose  from.  An  equivalence  relation  is  used  where  the 
sorts  (or  operations)  that  belong  to  the  same  equivalence  group  are  those  that  have  been  identified  by  the 
signature  mapping  as  being  “merged”.  Thus  if  sorts  Si  and  S2  of  specification  A  are  mapped  to  the  same 
sort,  P,  in  specification  Bl  then  sorts  Si  and  S2  form  an  equivalence  group  sort  in  specification  Z1  and  the 
Bl  sort  p  is  translated  to  that  equivalence  group  name.  Note  that  specification  Z1  will  still  be  a 
conservative  translation  of  specification  Bl  and  hence  an  isomorphism.  The  construction  for  the  sorts  and 
operations  of  the  pushout  specification  C  is  now  a  merging  of  the  equivalence  relations  instead  of  a  simple 
union  of  sets.  If  sorts  Si  and  S2  form  an  equivalence  group  sort  in  specification  El  and  sorts  S2  and  S3  form 
an  equivalence  group  sort  in  specification  S2  then  Si,  S2,  and  S3  form  a  single  equivalence  group  sort  in  the 
pushout  specification  C.  The  axioms  of  specifications  El  and  E2  (Bl  and  B2)  are  then  translated  using  the 
“names”  of  the  new  equivalence  group  sorts  and  equivalence  group  operations. 
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The  proof  that  the  extended  constructions  above,  which  remove  the  disjoint  name  and 
monomorphism  restrictions,  will  still  result  in  a  pushout  specification  is  left  as  an  exercise  for  the  reader. 

Note  that  the  pushout  specification  constructed  by  the  method  defined  in  Proposition  C.18  (and  its 
extensions)  is  not  unique.  There  are  many  other  suitable  specifications  that  are  isomorphic  to  the  one 
constructed  by  the  method  above.  Any  of  these  isomorphic  specifications  could  serve  as  the  pushout 
specification.  The  names  given  to  the  pushout  specification’s  sorts  and  axioms  are  completely  arbitrary  (as 
long  as  they  are  distinct  and  do  not  cause  further  “merging”).  Also,  any  set  of  axioms  that  has  the  same 
(isomorphic)  theory  in  its  closure  can  be  used.  In  fact  any  specification  that  is  isomorphic  to  the  one 
constmcted  could  be  used  as  the  pushout  specification.  For  example,  the  (translated)  axioms  of 
specification  A  could  be  added  to  the  pushout  specification  C  as  they  are  guaranteed  to  be  theorems  of  the 
specification.  Any  other  set  of  axioms  that  generate  the  same  theory  as  the  axioms  we  constmcted  for 
specification  C  could  also  serve  as  axioms  for  the  pushout  specification. 


C.2.2  Pushouts  in  Spec  preserve  morphism  properties 

In  Definition  A.15  a  pushout  was  defined  in  terms  of  arbitrary  specification  morphisms.  What  if 
the  specification  morphisms  were  one  of  the  extension  morphisms?  How  would  that  effect  the  constmcted 
morphisms? 

Proposition  C.19.  The  pushout  of  a  (conservative,  definitional)  extension  morphism  along  a  specification 
morphism  results  in  a  (conservative,  definitional)  extension  morphism. 


A  — e->Bl  A  —  c-^Bl 


A  — d  — B1 


B2  -  e  >  C  B2  c  >  C  B2 . d  C 

Proof:  The  constmction  method  from  Proposition  C.  1 8  (and  its  extensions)  are  used  in  this  proof.  As  any 
other  pushout  specifications  and  pushout  morphisms  will  be  isomorphic  to  the  ones  constmcts  and 
properties  like  the  extensions  are  preserved  under  isomorphic  changes  it  is  safe  to  reason  from  the 
particular  to  the  general  using  our  proposed  pushout  constmction  method. 

Extensions:  For  purposes  of  contradiction,  given  an  extension  morphism / :A->B1  and  morphism  g:A”^B2, 
assume  that  the  pushout  of f  along  g,/':B2^D,  is  not  a  monomorphism  (extension).  If f  \  where 
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/'  =  </ s,/ n>  is  not  a  monomorphism  then  there  must  exist  Si,  S2  e  5orts‘(B2)  such  that  Si  S2  and 
/  s(si)  =/ s(s2)  or  there  must  exist  /i,  g  Operations^!)  such  that  /i  and  /  n(/i)  Since  the 

arguments  are  the  same  we  will  work  with  the  sorts  Sj  and  S2.  It  is  given  that/is  an  extension 
(monomorphism).  By  the  construction  method  (and  its  extensions)  the  sorts  in  the  conservative  translation 
El,  which  is  based  on  f,  will  have  no  equivalence  group  sorts.  Also,  by  the  construction  method,  if 
Si,  S2  €  Sorts(Q2)  where  Si  ^  $2,  then  Si  and  S2  remain  different  sorts  in  the  conservative  translation  to 
specification  Z2.  This  means  that  when  the  (translated)  sorts  S\  and  S2  are  mapped  to  the  sorts  in 
specification  C  they  will  remain  separate  sorts  as  the  El  specification  contains  no  equivalence  group  sorts 
that  would  cause  the  E2  (B2)  sorts  to  be  merged.  By  this  reasoning  there  must  be  an  injective  mapping  of 
the  sorts  in  specification  B2  to  those  in  specification  C  and  there  does  not  exist  Si,  S2  e  Sorts(B2)  such  that 
Si  ^  S2  and/ s(si)  =/ s(s2)-  Similar  reasoning  applies  to  there  being  an  injective  mapping  of  operations 
from  B2  to  Specification  C.  The  sorts  Si  and  S2  and  operations /  and/  as  described  above  cannot  exist.  By 
this  contradiction  the  pushout  of  an  extension  morphism  along  any  other  specification  morphism  must 
result  in  an  extension  morphism. 

Conservative  Extensions:  For  purposes  of  contradiction,  given  a  conservative  extension  morphism 
/ :A-^B1  and  morphism  g:A-^B2,  assume  that  the  pushout  of f  along  g,f':B2—>D,  is  not  a  conservative 
extension  morphism.  By  the  proof  above  it  is  known  that /'  is  an  extension  morphism  so  it  must  not  be  the 
case  that  Axioms(C)  he  P  for  all  P  e  Z2-sentences  iff  Axioms(i:2)  p  where  E2  represents  both  B2^’,  the 

translated  source  specification  of  f\  as  well  as  the  conservative  translation  of  specification  B2  in  our 
pushout  construction  method.  Thus,  since  specification  C  combines  the  (translated)  axioms  of  El  and  E2, 
El  must  contain  axioms  that  affect  whether  ^^^^^(C)  he  P  for  some  E2-sentence  p.  However,  since /is  a 
conservative  extension  morphism  we  know  that^x/o/n.y(Bl)  hBi  a  for  all  a  g  A-sentences  \ffAxioms(A^ 
hA  a  where  A^is  the  translated  somce  specification  of /  Since  El  =  Bl,  El  is  also  a  conservative 
extension  of  A  and  the  same  properties  apply  for  axioms  over  the  translated  signature  of  specification  A. 
When  the  axioms  from  specifications  El  and  E2  are  combined  in  specification  C  they  share  references  to 
sorts  and  operations  that  originate  in  specification  A.  Specifically,  the  axioms  in  El  that  make  use  of  the 
sorts  and  operations  that  originate  in  specification  A  do  not  modify  the  entailment  relation  over  the 
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translated  A-sentences  and  therefore  do  not  modify  the  entailment  relation  over  that  same  shared  signature 
coming  from  specification  Z2  (B2).  Those  axioms  cannot  modify  the  entailment  relation  for  any  sentence 
that  involves  sorts  or  operations  that  do  not  originate  in  specification  A.  The  axioms  in  21  that  make  use  of 
the  extended  sorts  and  operations  (those  that  do  not  originate  in  specification  A)  cannot  modify  the 
entailment  relation  over  any  22  sentence.  Thus  the  axioms  of  21  either  do  not  modify  the  entailment 
relation  over  the  signature  of  22  because  they  are  conservative  in  nature  or  they  cannot  modify  the 
entailment  relation  because  they  involve  signature  elements  that  are  not  shared  between  the  specifications. 

By  this  contradiction  we  know  that  specification  21  contains  no  axioms  that  affect  whether 
Axioms{C)  Kc  P  for  some  22-sentence  p  and  our  original  assumption  is  wrong  and/  is  a  conservative 
extension. 

Definitional  Extensions:  For  purposes  of  contradiction,  given  a  definitional  extension  morphism/ :A->B1 
and  morphism  g:A— >B2,  assume  that  the  pushout  of/along  g,/':B2-^D,  is  not  a  definitional  extension 
morphism.  By  the  proof  above  it  is  know  that  / '  is  a  conservative  extension  morphism,  so  there  must  exist 
a  sort  in  specification  C  that  is  not  covered  by  the  morphism /  ':B2“->D  and  that  is  not  a  constructed  sort,  or 
there  must  exist  an  operation  in  specification  C  that  is  not  covered  by  the  morphism/ ':B2--^D  that  is  not 
total  and  functional.  However,  the  sorts  and  operations  that  are  not  covered  by  the  morphism  from  B2 
originate  from  21  (Bl).  Since/ :A-^B1  is  a  d-morphism,  these  sorts  are  all  constructed  sorts  and  the 
operations  are  all  total  and  functional.  By  construction,  the  translated  axioms  of  specification  Bl  (21), 
even  those  that  are  implicit  in  the  definition  clauses  and  sort-axioms,  are  part  of  specification  C.  Because 
the  entailment  relation  is  monotonic  and  consistent  under  translation,  the  properties  for  the  unmapped  sorts 
and  operations  remain  unchanged,  i.e,  all  extended  sorts  are  constructed  sorts  and  all  extended  operations 
are  total  and  functional  because  these  properties  are  still  theorems  of  the  translated  axioms.  By  this 
contradiction  we  know  our  original  assumption  to  be  wrong  and  f  is  a  definitional  extension.  □ 

C.2.3  Colimit 

In  the  category  Spec,  a  pushout  is  used  to  merge  two  specifications  based  on  a  third  specification 
that  indicates  how  the  other  two  specifications  relate  to  each  other.  A  colimit  in  Spec  is  used  to  construct 
the  minimum  aggregate  specification  for  an  arbitrary  diagram  of  component  specifications.  While  a 
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pushout  is  the  minimal  object  that  completes  a  commuting  square,  a  colimit  is  the  minimal  object  of  an 
arbitrary  diagram  of  objects  and  arrows  fliat  form  a  cocone  (a  collection  of  arrows  with  a  common 
codomain)  in  a  commuting  diagram.  A  pushout  is  a  particular  example  of  a  colimit 

Category  Spec  has  all  pushouts  for  any  pair  of  morphisms  of  the  form  B1<-A->B2  based  on  the 
constraction  mefliod  presented  in  Definition  A.  15.  According  to  Goldblatt  [Gol84]  any  category  that  has 
pushouts  and  an  initial  object  has  columts  for  arbitrary  diagrams,  i.e.  is  cocomplete.  For  the  Category 
Spec,  the  initial  object  is  the  empty  specification  as  it  has  a  unique  morphism  (the  empty  morphism)  to  any 
object  in  Spec.  Thus  the  category  Spec  has  colimits  for  all  diagrams. 

Figure  C-9  is  an  example  of  a  simple  colimit  and  its  meaning  defined  in  terms  of  pushouts.  The 
choice  for  the  intermediate  pushout  (Bl4-A-»B2,  B1<-A-^B3,  or  B2«-A^B3)  is  arbitrarily  chosen  in 
Figure  C-9(b)  to  be  B1<-A-^B2.  The  second  pushout.  Figure  C-9(c),  uses  the  result  of  the  first  pushout  to 
“add  in  the  stracture”  of  the  remaining  object  to  form  the  colimit  object,  C.  Regardless  of  the  intermediate 
pushout  choices,  the  resultant  C-object  will  be  the  minimal  cocone  object  and  hence  the  colimit. 


a.  Initial  diagram  b.  1st  pushout  c.  2nd  pushout  d.  Colimit 

Figure  C-9.  Colimit  example 

In  the  category  Spec,  given  any  base  diagram  of  specifications  and  morphisms,  the  colimit  can  be 
mechanically  constructed  [GB84].  Conqionent  specifications,  each  representing  a  part  of  the  overall 
problem  being  specified,  can  be  combined  via  colimit  to  form  a  larger  specification  that  represents  the 
requirements  of  the  problem  as  a  whole. 

Since  a  diagram  of  specifications  and  specification  and  morphisms  can  be  depicted  as  a  graph,  a 
Spec  diagram  can  be  represented  syntactically  as  a  graph  by  labeling  nodes  and  arcs  with  specifications  and 
specification  morphisms.  The  following  Specware  language  code  is  used  to  develop  the  diagram  for 
Example  C.17,  a  set  of  flags.  The  "nodes”  statement  lists  the  specifications  in  the  diagram  (Set,  One-Sort, 
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and  Flag)  and  the  “arcs”  statement  identifies  (defines)  the  morphisms  between  those  specifications.  This 
limited  diagram  statement  forms  the  basis  of  the  diagram  statement  developed  in  Chapter  5. 


Diagram  Set-of-Flags  is 
nodes  Set,  One -Sort,  Flag 
arcs  One -Sort - >Set :  {X->E}, 

One -Sort ->Flag:  {x->Flag} 
end-diagram  _ 


The  following  Specware  language  code  is  used  to  develop  the  colimit  object  of  the  Set-of-Flags 
diagram.  Thus  specification  Set-of-Flags  is  the  colimit  of  the  diagram  Set-of-Flags. 

Spec  Set-of-Flags  is 

Colimit  of  Set-of-Flags  _ _  _ _ 


Using  this  syntax  it  is  possible  to  specify  and  take  the  colimit  of  any  finite  diagram  of 
specifications  and  specification  moiphisms.  In  the  next  section  the  various  refinement  mechanisms  are 
described  and  the  mechanism  by  which  the  refinements  of  the  individual  component  specifications  of  a 
diagram  can  be  combined  to  produce  a  refinement  of  the  colimit  of  the  diagram  is  described. 

C  3  Refinement  of  Specifications 

So  what  does  it  mean  for  one  specification  to  be  a  refinement  of  another?  Informally,  if  every 
possible  implementation  of  specification  B  is  also  an  implementation  of  specification  A,  then  specification 
B  is  a  refinement  of  specification  A  [ST88].  By  Proposition  B.39  if  there  is  a  specification  morphism  a 
from  specification  A  to  specification  B,  then  all  models  (implementations)  of  B  will  also  be  models 
(implementations)  of  A  because  of  the  a-reduct  functor.  Since  the  a-reduct  functor  need  not  be  suijective 
there  may  be  some  models  of  specification  A  that  cannot  be  reached  by  the  a-reduct  functor  from  models 
of  specification  B.  This  means  that  the  design  choice  (refinement)  has  eliminated  some  of  the  possible 
implementation  models  of  specification  A.  Since  the  a-reduct  functor  need  not  be  injective  there  may  be 
many  models  of  specification  B  that  are  mapped  to  the  same  specification  A  model  by  the  a-reduct  functor. 
This  means  that  fliere  may  be  many  implementations  (carrier  sets  and  functions)  associated  with  the  sorts 
and  operations  that  are  not  in  the  image  of  a.  (The  refinement  design  choice  that  introduced  some 
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underlying  implementation  sorts  and  operations  has  not  constrained  them  so  that  a  single  class  of  carrier 
sets  and  functions  can  implement  them.) 

Using  a  morphism  as  the  refinement  relation  between  specifications  tightly  couples  the  two 
specifications  in  that  all  of  the  sorts  and  operations  of  the  source  specification  must  have  a  direct  map  in  the 
target  specification.  An  example  morphism  refinement  is  Abstract-Set  ->  Concrete-Set  where  the  spec 
Concrete-Set  may  contain  additional  “implementation”  sorts  and  operations  and/or  may  contain 
constructive  definitions  for  the  Abstract-Set  sorts  and  operations.  In  practical  terms,  a  morphism  between 
specifications  means  that  if  one  can  implement  the  target  specification  of  the  morphism  then  one  has  also 
developed  an  in^lementation  of  the  source  specification. 

One  issue  with  using  a  morphism  as  the  refinement  mechanism  is  that  it  does  not  expose  any  of 
the  internal  structure  of  the  target  specification.  Not  only  must  one  refine  (implement)  the  codomain 
specification  sorts  and  operations  that  are  targets  of  the  morphism  from  the  source  specification,  but  one 
must  also  implement  the  additional  supporting  sorts  and  operations  that  are  in  the  codomain  specification. 
While  hiding  structure  may  be  good  from  an  abstraction  standpoint,  it  is  bad  if  one  is  trying  to  specify 
design  information.  If  one  assumes  that  the  target  of  the  specification  morphism  is  an  extension  of  some 
other  specification,  then  this  internal  design  structure  is  exposed  and  c^  be  manipulated. 

C,3.1  Interpretations 

Proposition  B.39  indicates  that  a  specification  morphism  can  be  used  as  a  refinement  mechanism. 
However,  a  refinement  of  a  specification  by  morphisms  is  not  powerful  enough  to  represent  the  types  of 
refinement  that  occur  in  software-engineering  as  it  is  rare  that  an  existing  specification  (or  implementation) 
can  serve  directly  as  the  target  of  a  morphism.  Instead,  an  existing  specification  must  usually  be  extended 
in  order  to  provide  the  appropriate  sorts  and  operations  that  serve  as  a  target  for  a  specification  morphism. 

This  more  general  refinement  relation  between  the  source  specification  and  the  extension  of  a 
target  specification  is  called  an  interpretation  [Ehr82].  In  an  interpretation,  there  is  a  morphism  from  the 
source  specification  to  a  definitional  extension  of  the  target  specification.  A  definitional  extension 
morphism  is  used  because  this  morphism  can  be  viewed  as  an  implementation  construction  mechanism  as 
discussed  in  Section  C.  1 .5. 
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Deflnition  C.20,  An  interpretation,  i  =  <fg>,  consists  of  a  specification  morphism  /  and  a  definitional 
extension  morphism  g  with  a  common  codomain  specification,  cod(/)  =  cod(  g  ).  The  domain  of  the 
specification  morphism  is  called  the  domain  (or  source)  of  the  interpretation,  dom(  i)  =  dom(/).  The 
domain  of  the  definitional  extension  morphism  is  called  the  codomain  (or  target)  of  the  interpretation, 
cod(  I )  =  dom  (g)  and  the  codomain  of  both  morphisms  is  called  the  mediator  of  the  interpretation, 
mediator(  i )  =  cod(/)  =  cod(  g ).  An  interpretation  from  specification  A  to  specification  B  is  depicted  as 
A  —>  A-aS“B  <—d—  B,  A  — >  B^  B,  or  A  ^  B. 

Thus  an  interpretation  fi*om  specification  A  to  specification  B  is  a  morphism  from  specification  A 
to  a  specification  B'^  that  is  a  definitional  extension  of  specification  B  that  has  added  (fully  defined)  A-like 
sorts  and  operations.  Specification  A  is  interpreted  as  (refined  to,  implemented  as,  etc)  a  definitional 
extension  of  specification  B.  The  morphism  refinement  generalizes  to  an  interpretation  refinement,  as  any 
specification  morphism  A—>B  can  be  generalized  to  an  interpretation,  i.e.  A— >  B  4-id-  B. 

Example  C.21.  An  interpretation  from  specification  Set  to  specification  Bag,  Set  =>  Bag,  via  the  mediator 
Set-as-Bag,  is  depicted  in  Figure  C-10.  The  extensions  in  the  mediator  Set-as-Bag  are  set-like  sorts  and 
operations  that  are  defined  using  the  sorts  and  operations  of  specification  Bag.  This  interpretation  means 
that  any  implementation  of  Bag  may  be  extended  with  set-like  ftmctions  that  is  an  implementation  of  both 
the  Set-as-Bag  mediator  specification  and  by  Proposition  3.8,  the  Set  specification. 

Notation;  The  symbols  f  and  i  in  specification  Set-as-Bag  in  Figure  C-10  are  implicit  operations  that 
are  defined  based  on  the  subsort  relation  in  that  specification,  i.e.  the  text  “sort  -  axiom  Set  =  Bag  | 
no -dupes”.  Up-arrow,  t,  is  the  super-sort  operation  and,  for  the  given  example,  is  defined  as  follows: 
t  -  (relax  no-dupes)  where  t  :Set->Bag  takes  in  a  subsort  and  returns  the  sort  from  which  it  was 
constructed.  Down-arrow,  I ,  is  the  inverse  of  t  but  is  only  a  partial  function  over  its  domain.  Down-arrow 
is  defined  as  follows:  t(l(s))  =  s  and  t  is  undefined  outside  the  range  of  1.  It  is  partially  defined  as  only 
the  “bags”  that  have  no  duplicates  can  be  directly  “converted”  to  the  set  subsort.  The  obvious  proof 
obligation  associated  with  the  use  of  i  is  that  it  only  be  used  in  those  contexts  where  its  restriction  (no- 
dupe(s))  ensures  it  is  defined. 
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spec  Set  is 
sort  Set,  E 

op  Empty:  ->  Set 

op  Insert:  E,  Set  ->  Set 

op  In:  E,  Set  ->  Boolean 

Constructors  {Empty,  Insert}  construct  Set 

Forall  s:Set,  e,el,e2:E 

Ax  not (In (e, Empty) ) 

Ax  in (el, Insert (e2 , s) )  =>  ({el=e2)  v  In{el,s)) 

Ax  Insert (e,s)  =  Insert (e, Insert (e, s) ) 

Ax  Insert (el, Insert (e2,s))  =  Insert (e2 , Insert (el, s) ) 

end- spec _ _ _ 

{Empty  set-Empty,  Insert^set-Insert,  In“>set-In} 


Spec  Set-as-Bag  is 
Protect  Bag 
sort  set 

sort -axiom  Set  =  Bag  |  no- dupes 
op  set-Empty:  ->  Set 

op  set -Insert:  E,  Set  ->  Set 
op  set -In:  E,  Set  ->  Boolean 

op  no-dupes :  bag  ->  Boolean 

Constructors  (set-Empty,  set- Insert)  construct  Set 
Forall  s,sl,s2:Set,  e,el,e2:E,  b:Bag 
define  no -dupes  by 
ax  no -dupes (Empty) 

ax  no-dupes  (insert  (e,b) )  <=>  no-dupes  (b)  a  not(in(e,b)  ) 
define  set-Empty  by 

ax  set-Empty  =  1 (Empty) 
define  set-insert  by 

ax  set-insert (e, s)  =  if  in(e,t(s))  then  s  else  1 (insert (e, I (s) ) ) 
define  set -In  by 

ax  set-in(e,s)  =  in(e,t(s)) 
end- spec 

fT) 

_ _J - — - 

Spec  Bag  is 
sort  Bag ,  E 

op  Empty:  ->  Bag 

op  Insert:  E,  Bag  ->  Bag 

op  In:  E,  Bag  ->  Boolean 

Constructors  (Empty,  Insert)  Construct  Bag 

Forall  b,bl,b2:Bag,  e,el,e2:E 

Ax  Not  (in (e, Empty) ) 

Ax  in (el , insert (e2 ,b) )  =>  (el=e2  v  in(el,b)) 

Ax  (insert (e,bl)  =  Insert (e,b2) )  =>  (bl=b2) 

Ax  Insert (el, Insert (e2,b) )  =  Insert (e2, Insert (el, b) ) 
end- spec _ _ 

Figure  C-10.  Interpretation:  Set  as  Bag 


An  interpretation  such  as  that  in  Figure  C-10  can  be  represented  syntactically  by  the  following 

Specware  language  code: 

Interpretation  Set  =>  Bag  is 
Mediator  Set-as-Bag 

Dom-to-med  (Empty  set-Empty,  Insert->set -Insert,  In->set-In} 
Cod-to-med  {} 


The  interpretation  in  Figure  C-1 1  is  depicted  in  two  dimensions  so  that  the  meaning  of  an 
interpretation  can  be  better  related  to  software-engineering  concepts.  Specification  A  is  thought  of  as  being 
on  the  abstract  requirement  level  and  specification  B  is  thought  of  as  being  on  the  concrete  implementation 
level  even  though  all  the  specifications  (levels)  may  be  very  abstract.  The  vertical  arrow  represents  a 
design  decision  and  a  change  in  layers  that  has  (probably)  eliminated  some  of  the  possible 
implementations.  (Some  of  the  models  of  specification  A  are  no  longer  represented  amongst  the  models  of 
specification  because  the  design  decision  represented  by  the  vertical  arrow  has  eliminated  them.)  The 
horizontal  arrow  also  represents  a  design  decision;  it  details  how  an  existing  implementation  (models  of  B) 
can  be  extended  to  provide  an  implementation  of  specification  A.  The  horizontal  arrow  is  a  d-morphism 
that  represents  fimctionality  that  has  been  added  to  (and  constructed  from)  an  existing  class  of  models 
(implementations).  The  angled  double  arrow  represents  the  interpretation  that  is  composed  of  the  layer 
changing  and  model  reducing  vertical  morphism  combined  with  the  functionality  adding  and  model 
extending  horizontal  morphism. 

Abstract  Requirement 


Concrete  Implementation 

Figure  C-11.  Interpretations  and  refinement  layers 

Any  implementation  (model)  of  the  target  specification  of  an  interpretation,  specification  B  in 
Figure  C-11,  can  be  extended  (sometimes  mechanically)  to  implement  the  mediator  specification  and  hence 
the  source  specification,  specification  A  in  Figure  C-1 1.  More  formally,  there  is  a  functor  that  takes 
models  of  specification  B  to  models  of  specification  A.  Thus  in  one  sense,  all  models  of  specification  B  are 
models  of  specification  A,  which  fits  the  requirement  for  a  refinement  [ST88].  In  Section  C.1.5  the  functor 
that  uniquely  extends  models  of  a  specification  to  models  of  its  definitional  extension  (specification  B  to 
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models  of  specification  in  Figure  C-1 1)  was  described.  A  reduct  functor  takes  models  of  specification 

to  models  of  specification  A.  By  composing  the  two  functors,  a  fimctor  that  takes  models  of 
specification  B  to  models  of  specification  A  is  derived,  thus  justifying  the  use  of  interpretations  as  a 
refinement  mechanism. 

If  one  did  not  already  have  a  concrete  implementation  of  the  target  specification  of  the 
interpretation,  specification  B,  then  one  could  use  the  interpretation  refinement  mechanism  a  second  time  to 
refine  specification  B  by  itself.  Thus  in  one  sense  the  problem  has  been  broken  down  and  partitioned  better 
than  with  the  morphism  refinement  mechanism.  With  an  interpretation  refinement  from  specification  A  to 
specification  B,  to  implement  specification  A  one  must  often  only  implement  specification  B  as  the 
definitional  extension  morphism  from  B  to  B"^  may  be  used  to  mechanically  extend  models  of  B  to  be 
models  of  B*^  and  hence  models  of  A. 


C.3.2  Interpretations  and  definitional  extensions 

Given  a  morphism  A->C  and  a  refinement  (interpretation)  of  specification  A,  A=^B,  it  would  be 
useful  if  a  compatible  refinement  of  specification  C  could  be  mechanically  generated  from  the 
interpretation  A=^B,  Unfortunately  such  a  construction  is  mechanical  only  if  the  morphism  A-^C  is  a 
definitional  extension. 

Proposition  C.22.  Given  an  interpretation  A=>B  and  a  definitional  extension  morphism  A-d^C,  an 
interpretation  C:=>B  can  be  mechanically  generated. 

Proof:  On  the  left  in  Figure  C-1 2  is  a  diagram  consisting  of  an  interpretation  A=>B  and  a  definitional 
extension  morphism  A-^— >C.  The  pushout  of  (sub)diagram  C<— d— A^B^  results  in  a  specification  B  and 
morphisms  C-^B"^  and  B'^-d^B'^^  as  depicted  on  the  right  in  Figure  C-1 2.  By  composing  d-morphisms 
B-d~>B'^  and  B'^-d-->B^,  the  d-morphism  B-d-^B"^  is  derived  as  depicted  on  the  right  in  Figure  C-1 2. 

The  (sub)diagram  C^B^<-d-B  is  the  interpretation  C=>B.  I 

A  - ►  B+  - d - -  B  A - ►  B+  - d - B 


I 

d 

i 

C 


I  i 

d  d 

1  i 

C  - •►B+' 

Figure  C-12.  Constructing  an  interpretation  for  a  definitional  extension 
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The  automatic  constraction  of  the  interpretation  C=^B  has  mechanically  taken  the  definitional 
extension  axioms  in  A— d— and  transferred  and  translated  them  so  that  they  are  definitional  extension 
axioms  of  specification  B^.  From  the  perspective  of  models  this  makes  sense;  if  a  model  of  specification  A 
is  uniquely  extended  then  an  implementation  of  that  model  should  be  able  to  be  umquely  extended  in  die 
same  maimer. 

C.3.3  Composition  of  interpretations 

For  interpretations  to  be  a  viable  means  for  refining  specifications,  successive  interpretations 
should  compose.  If  interpretations  compose,  then  the  design  decisions  made  in  each  individual 
intermediate  interpretation  can  be  combined  into  a  single  interpretation  reflecting  all  of  the  design 
decisions.  This  would  enable  the  initial  requirement  specification  to  be  viewed  as  a  definitional  extension 
of  the  final  design  specification. 

Definition  C.23.  Arbitrary  interpretations  A  =>  B  and  B  =>  C  fliat  have  a  common  codomain/domain 
specification  compose  to  form  an  interpretation  A  =>  C  as  depicted  in  Figure  C-13.  Figure  C-13  (a)  depicts 
two  interpretations,  A  — >  B^  <— d—  B  and  B  — >  <  d~  C  with  a  common  domain/codomain.  The  A  layer  is 

implemented  by  (refined  into)  the  B  layer  that  in  turn  is  implemented  by  (refined  into)  the  C  layer.  In 
Figure  C-13(b),  a  pushout  fi-om  diagram  B"^  <-d-  B  C"  is  used  to  mechanically  construct  specification 

C”.  Finally,  in  Figure  C-13(c)  the  vertical  morphisms  and  horizontal  d-morphisms  are  composed  to  form 
the  interpretation  A  — >  d-  C. 


a.  A  =>  B  =>  C  b.  B+  B  C+  Pushout  c.  A  =>  C  Interpretation 

Two  Interpretations  Construction  of  Mediator  by  Morphism  Composition 


Figure  C-13.  Composition  of  interpretations  in  Spec 

For  evample,  in  Figure  C-14  there  is  an  interpretation  from  specification  Bag  to  specification  List, 
Bag  =>  List.  This  can  be  composed  with  the  interpretation  Set  =>  Bag  to  form  an  interpretation  Set  =>  List, 
Figure  C-15. 
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Notation:  The  Angled- Arrow,  in  Figure  C-14  is  defined  to  be  the  quotient  operation  based  on  the 
quotient  sort.  In  specification  List-as-Bag,  Figure  C-14,  /:  List->Bag,  is  defined  as  follows: 

=  (quotient  perm). 


Spec  Bag  is 
sort  Bag,  E 

op  Empty:  “>  Bag 

op  Insert:  E,  Bag  ->  Bag 

op  In:  E,  Bag  ->  Boolean 

Constructors  {Empty,  Insert}  Construct  Bag 

Forall  b,bl,b2:Bag,  e,el,e2:E 

Ax  Not (in (e, Empty) ) 

Ax  in (el, insert (e2,b) )  (el=e2  v  in(el,b)) 

Ax  (insert (e,bl)  =  Insert (e,b2) )  =>  (bl=b2) 

Ax  Insert (el, Insert (e2,b))  =  Insert (e2, Insert (el, b)) 
end- spec _  ' _ _ _ _ 

^  {Empty bat-Empty,  Insert->bag-Insert,  In-^bag-In} 

Spec  Bag-as-List  is 
Protect  List 
sort  Bag 

sort-axiom  Bag  =  List/Perm 

op  Bag-Empty:  ->  Bag  op  Perm:  List,  List  ->  Boolean 

op  Bag-Insert:  E,  Bag  ->  Bag  op  Count:  E,  List  ->  Nat 

op  Bag -In:  E,  Bag  ->  Boolean 

Constructors  (bag-Empty,  bag- Insert)  Construct  Bag 
Forall  b,bl,b2:Bag,  e,el,e2:E,  l,ll,12:List 
define  Count  by 

ax  Count (e, Empty)  =  0 

ax  Count (el, insert (e2 , 1) )  =  if  el=e2  then  Count (el, 1)  +  1 

else  Count (el, 1) 

define  Perm  by 

ax  Perm(ll,12)  <=>  (Count  (e,  11)  =  Count  (e,  12)) 
define  bag-Empty 

ax  bag-Empty  =  (Empty) 
define  bag-insert 

ax  bag-insert  (e,  (1) )  =  (Append (e,  1) ) 

define  bag -In 

ax  Not (bag-In(e, bag-Empty) ) 

ax  bag-In (el, bag-insert  (e2 , 1) )  <=>  (el=e2  v  bag-In (el,  1) ) 
end- spec 

_ I _ 

Spec  List  is 
sort  List,  E 

op  Empty;  ->  List 

op  Append:  E,  List  ->  List 
op  In:  E,  List  ->  Boolean 

Constructors  (Empty,  Append)  Construct  List 
Forall  s , si , s2 : List ,  e , el , e2 , e3 , e4 : E 
Ax  Not  (in  (e,  Empty) ) 

Ax  in (el, Append ( e2,  s) )  ^  (el=e2  v  in(el,s)) 

Ax  (Insert (el, si)  =  Insert (e2 , s2) )  o  (el=e2  a  s1=s2) 

Ax  (Insert  (el.  Insert  (e2 ,  s) )  =  Insert  (e3 ,  Insert  (e4 ,  s)  )  <=>  (el=e3  a  e2=e4) 
end-  spec _ _ 

Figure  C-14.  Interpretation:  Bag  as  List 
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If  the  source  of  an  interpretation  is  a  commonly  used  specification,  the  interpretation  should  be 
placed  in  a  library  so  that  it  may  be  reused.  The  next  section  addresses  how  collections  of  interpretations 
are  currently  used  to  refine  aggregate  structures  (diagrams). 


C  4  Refinement  of Diagrams  of  Specifications 

Colimits  are  used  to  form  an  aggregate  specification  from  component  specifications.  Diagram 
refinement  is  a  technique  that  enables  the  interpretations  from  component  specifications  to  be  combined  so 
that  their  aggregate  forms  an  interpretation  of  the  aggregate  of  the  components.  In  order  to  put 
interpretations  together  in  a  fashion  similar  to  how  the  specifications  are  put  together  there  needs  to  exist 
motphisms  between  interpretations. 

C.4. 1  Interpretation  morphisms 

An  interpretation  morphism  (morphism  between  interpretations)  ensures  that  the  “structure”  of 
one  interpretation  is  preserved  in  another  in  the  same  manner  that  a  specification  morphism  ensures  that  the 
“structure”  of  one  specification  is  preserved  in  another.  An  interpretation  morphism  consists  of 
specification  morphisms  between  the  domain,  mediator,  and  codomain  specifications  of  the  interpretations. 
Definition  C.24,  An  interpretation  morphism  is  a  5  tuple,  im  =  <A  =>  B,  C  =>  D,/  :A-^C, 

A:B^D>,  where  dom(i>w)  =  A=>B,  cod(z>w)  =  Cr:>D,  dom-morphism(z>w)  =/,  cod-morphism(fm)  =  h, 
med-morphism(i>w)  =  g,  consisting  of  the  domain  and  codomain  interpretations  and  three  morphisms 
between  the  domain,  codomain  and  mediator  specifications  of  the  domain  interpretation  to  the  domain. 


234 


codomain  and  mediator  specifications  of  the  codomain  interpretations,  such  that  the  diagram  in  Figure  C-16 
commutes. 

Domain  Interpretation  A - ^  B"*”  ^ - d -  B 

Inteipretation  Moiphism 

i  i  i  i  i  1 

Codomain  Interpretation  C  - ►  ^ - d -  D 

Figure  C-16.  Interpretation  Morphism  I 

The  commutativity  of  the  specifications  making  up  the  inteipretation  morphism  diagram. 

Figure  C-16 ,  is  evidence  that  the  structure  of  one  interpretation  is  preserved  in  the  other.  The  full  structure 
is  often  left  off  a  diagram  involving  interpretations  and  interpretation  moiphisms  in  order  to  reduce  the 
clutter.  Figure  C- 17  is  an  alternate  depiction  of  the  interpretation  morphism  of  Figure  C-16. 

A  r  B 

C  — .  ^  I  D 

Figure  C-17.  Interpretation  Morphism  n 

C  4.2  The  category  Interp 

In  order  to  construct  an  aggregate  refinement  from  a  collection  of  related  refinements  the 
refinements  themselves  must  be  treat  as  objects  that  can  be  combined.  Inteipretations  and  interpretation 
moiphisms  can  be  treated  as  the  objects  and  arrows  of  a  category,  and  the  categorical  colimit  and 
composition  constructs  can  be  used  to  construct  such  a  refinement  aggregate. 

Proposition  C.25.  Interpretations  and  Interpretation  moiphisms  form  a  category,  Interp,  where  the  objects 
are  interpretations  between  speciftcations  and  the  arrows  are  interpretation  moiphisms. 

Proof:  For  any  given  inteipretation  d-B,  the  identity  interpretation  moiphism  is  the  5-tuple 

>B^<“d—  B,  A— ^B^^d—B,  Ajj,  B^  ^id,  Bid>,  where  the  domain,  codomain  and  mediator  specification 
moiphisms  are  the  identity  moiphisms  for  those  specifications.  Interpretation  moiphisms  compose  because 
the  individual  specification  moiphisms  making  up  the  interpretation  moiphisms  compose.  Composition  of 
Interpretation  moiphisms  is  associative  because  composition  of  the  individual  specification  moiphisms 
making  up  the  inteipretation  morphism  is  associative.  □ 
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There  are  three  obvious  forgetful  functors  (functors  that  remove  imderlying  object  and  arrow 
structure)  from  Interp  to  Spec  based  on  the  domain,  codomain  and  mediator  specifications  making  up  an 
interpretation  and  the  morphisms  between  those  specifications  that  make  up  an  interpretation  morphism. 
Proposition  C.26.  The  functor  T>om\Interp^Spec  is  the  pair  of  functions  <Domobjectj  Doihaitow^  where 
Domobject(0  =  dom(0  for  all  i  e  Objects(/nfe^)  and  DomAnowC^w)  =  dom-morphism(z>w)  for  all 
im  G  Anows>{Interpy  The  functors  Cod:  Interp-^Spec  and  Med  Interp-^Spec  are  similarly  defined  over 
the  functions  cod  and  cod-morphism,  and  the  functions  mediator  and  med-moiphism  respectively. 

Proof:  The  identity  arrows  are  preserved  as  DomArTow(idim)  ==  dm)  ^  Oh}ects{Interp). 

Composite  arrows  are  preserved  as  DomArrowC  ^  ®/)  =  DoniAiTowCg)  ®  DomArrow(/)  whenever  g  ©/is 
defined  in  Interp.  □ 

A  diagram  in  the  category  Interp  consists  of  a  collection  of  nodes  labeled  with  interpretations  and 
a  collection  of  arcs  between  the  nodes  labeled  with  interpretation  morphisms.  The  functors  Dorn,  Cod,  and 
Med  reduce  Interp  diagrams  to  Spec  diagrams.  Thus  for  an  Interp  diagram  D,  the  notation  Dom(D)  (and 
Cod(D)  and  Med(D))  is  used  to  reference  the  diagrams  in  Spec  that  have  the  same  shape  of  diagram  D  but 
that  consist  of  the  domain  (and  codomain  and  mediator)  specifications  and  morphisms  of  the  interpretations 
in  the  interpretation  diagram. 

C.4.3  Colimits  of  interpretations 

Since  an  interpretation  is  constructed  from  specifications  and  specification  morphisms  and  an 
interpretation  morphism  is  constructed  from  specification  morphisms,  it  is  natural  that  a  colimit  in  the 
category  Interp  be  constructed  from  the  colimits  of  its  components  in  the  category  Spec.  This  colimit 
operation  is  what  is  used  to  form  an  aggregate  interpretation  from  a  diagram  of  interpretations. 

Proposition  C.27.  A  colimit  object  C  of  a  diagram  D  in  the  category  Interp  can  be  constructed  by  taking 
the  colimits  of  diagrams  Dom(D),  Cod(D),  and  Med(D)  to  construct  the  domain,  codomain,  and  mediator 
objects  of  C  and  then  constructing  witness  arrows  from  specifications  dom(C)  and  cod(C)  to  specification 
mediator(C).  The  interpretation  morphisms  to  this  constructed  interpretation  in  the  category  Interp  are  the 
cocone  morphisms  from  the  three  colimit  morphisms  of  the  Dom,  Cod,  and  Med  diagrams  in  Spec. 
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Proof:  In  order  to  prove  the  construction  above  is  valid  it  must  proven  that  it  results  in  a  commuting 
diagram  where  the  constructed  interpretation  has  a  unique  interpretation  morphism  to  the  cocone  object 
(interpretation)  of  any  odier  commuting  diagram  in  category  Interp:  Figure  C-18  represents  a  typical 
example  of  an  interpretation  diagram.  The  collections  of  objects  and  solid  arrows  in  the  top  half  of  the  two 
diagrams  in  Figure  C-18  represent  the  initial  Interp  diagram,  i.e.  four  interpretations  (double  lines)  with 
three  interpretation  morphisms  coimecting  them  (triple  lines).  The  collections  of  dashed  arrows  in  the 
bottom  half  of  Figure  C-18  represent  the  constructed  colimit  object  and  cocone  morphisms. 

Existence  of  Colimit  Object:  It  is  easy  to  see  how  the  domain,  codomain  and  mediator  objects  of  the 
desired  colimit  (interpretation)  object  are  constructed  by  taking  colimits  in  category  Spec  over  the  domain, 
codomain  and  mediator  (sub)diagrams  of  the  interpretation  diagram.  In  Figure  C- 19(a)  the  colmnts  for  the 
domain  and  mediator  specifications  are  depicted.  There  exists  a  unique  arrow  from  the  colimit  object  of 
the  domain  specifications  to  the  colimit  object  of  the  mediator  specifications  (and  from  codomain  colimit  to 
mediator  colimit )  as  the  mediator  colimit  object  is  a  cocone  object  of  the  domain  (and  codomain) 
specification  diagrams.  In  Figure  C- 19(b)  the  cocone  arrows  to  F^  can  be  composed  with  the  domain  to 
mediator  arrows  of  the  interpretations  so  that  specification  F^  is  a  cocone  object  with  respect  to  the  diagram 
of  domain  specifications.  Since  specification  C  is  a  colimit  object  and  specification  F^  is  a  cocone  object 
from  the  same  diagram  of  specifications,  there  is  a  unique  arrow  from  C  to  F.  The  arrow  from  the 
codomain  specification  to  the  mediator  specification  can  be  similarly  constructed.  The  codomain  to 
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mediator  arrow  is  guaranteed  to  be  a  definitional  extension  morphism  as  d-morphisms  are  closed  under 
parallel  composition  [SJ95]. 


Figure  C-19.  Constructing  a  witness  arrow 


Existence  and  Uniqueness  of  Arrow:  Assume  there  exists  anoflier  cocone  interpretation,  G,  firom  diagram 
D.  dom(G)  is  a  cocone  object  of  Dom(D)  and  by  construction  dom(C)  is  the  colimit  object  of  Dom(D). 
Thus  by  Definition  A.  1 7,  there  is  a  unique  arrow  from  dom(C)  to  dom(G).  Similarly  there  are  unique 
arrows  from  med(C)  and  cod(C)  to  med(G)  and  cod(G)  respectively.  Together  these  three  arrows  form  a 
unique  interpretation  morphism  from  interpretation  C  to  interpretation  D.  The  overall  diagram  commutes 
as  the  three  individual  colimit  to  cocone  diagrams  commute.  I 

The  interpretation  colimit  object  for  any  interpretation  diagram  can  be  constmcted  mechanically. 
First  take  the  colimits  of  the  source  and  target  diagrams.  Every  specification  and  morphism  except  the 
mediator  specification  of  the  interpretation  object  and  all  of  the  specification  morphisms  to  the  mediator 
specification,  i.e.  specification  F'^  and  morphisms  to  specification  F*  in  Figure  C-19  are  now  known.  The 
mediator  is  mechanically  constructed  by  taking  the  colmut  of  the  entire  diagram,  including  the  newly 
constmcted  domain  and  codomain  specifications.  All  of  the  missing  morphisms  are  the  mechanically 
constmcted  cocone  morphisms. 


C.4.4  Diagram  refinement 

In  diagram  refinement  a  collection  of  source  specifications  is  individually  refined  to  a  collection  of 
target  specifications  via  interpretations.  The  source  specifications  are  related  in  that  there  are  specification 
morphisms  between  them.  Likewise  the  target  specifications  are  related  by  specification  morphisms. 
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Furthermore,  the  interpretations  have  interpretation  morphisms  between  them.  If  all  of  these  specification 
morphisms  and  interpretation  morphisms  are  consistent  (the  top  half  of  Ihe  diagrams  in  Figure  C-20 
commute)  then  an  interpretation  from  the  colimit  of  the  source  specifications  to  die  columt  of  the  target 
specifications  (the  bottom  half  of  diagrams  in  Figure  C-20)  can  be  mechanically  constructed. 


a.  Source  and  Target  diagrams  have  the  b.  Source  and  Target  diagram  have 

same  shape,  their  consistency  is  obvious  different  but  still  consistent  shapes 


Figure  C-20.  Diagram  reflnement 

The  following  definition  for  diagram  refinement  comes  from  [SJ95]. 

Definition  C.28.  Given  two  diagrams  of  specifications  Di'.G \->Spec,  and  D2:G2“>iSpec  where  Di  and  D2 
are  shape  mappings  from  the  category  of  graphs  (imlabeled,  directed  multi-graphs  and  morphisms  between 
graphs)  to  the  category  of  specifications,  and  Gi  and  G2  are  particular  shapes  (graphs),  a  diagram 
refinement  is  a  pair  <5,  cr>:Di->D2  where  b.G\--^Interp  is  a  diagram  of  interpretations  and  a:Gi-->G2  is 
functor  between  the  two  shapes  such  that  the  following  diagram  commutes  (Dom  and  Cod  are  the  functors 
from  Interp  to  Spec). 


Figure  C-21.  Necessary  relationship  between  specifications  and  shapes  in  a  diagram  refinement 
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If  the  source,  target,  and  interpretation  shapes  are  the  same,  as  in  Figure  C-20(a)  where  Gi=G2, 
then  the  interpretation  between  the  colimits  is  the  colimit  of  the  diagram  of  interpretations.  If  the  source 
and  target  shapes  are  different,  as  in  Figure  C-20(b)  where  Gi^25  an  additional  step  is  needed.  First  take 
the  colimit  of  the  diagram  of  interpretations  as  before,  then  compose  that  interpretation  with  a  morphism 
from  its  codomain  to  die  colimit  object  of  a  diagram  of  target  specifications  with  shape  G2,  see  Figure  C- 


The  shape  morphisms  from  the  target  diagram  with  shape  Gi  to  shape  G2  exist  as  the  (sub)diagram 
that  relates  those  shapes  in  Figure  C-22  commutes.  The  morphism  from  specification  F°  to  specification  F 
exists  because  F  is  also  a  cocone  object  of  the  target  diagram  with  shape  Gi,  see  Figure  C-19.  The  proof 
that  interpretation  C=:>F°  and  morphism  F°'->F  compose  to  interpretation  C=>F  is  depicted  in  Figure  C-23 
where  advantage  is  taken  of  the  fact  that  definitional  extension  morphisms  are  preserved  by  pushouts. 


240 


c - ►  F+  - d - F° 

1 

\  ^ 

. d - F 

Figure  C-23.  An  interpretation  composed  with  a  (target)  morphism 

Example  CJ9.  Refinement  of  Set-of-Flag  to  List-of-Flag.  In  Example  C.17  (Figure  C-7),  The  Set-of- 
Flags  specification  is  developed  from  a  pushout  involving  the  specifications  Set,  One-Sort,  and  Flag,  In 
Figure  C-l  5  the  Set  specification  is  refined  to  the  List  specification  via  the  interpretation  Set  List,  The 
assumption  in  this  example  is  that  the  Set  ADT  is  to  be  implemented  as  a  List  ADT  while  leaving  the 
implementation  of  specification  Flag  alone.  Thus  at  the  start  of  die  refinement  the  diagram  is  as  depicted 
on  the  left  in  Figure  C-24.  In  order  to  form  an  interpretation  from  specification  Set-of-Flag  to  specification 
List-of-Flag  a  family  of  compatible  interpretations  is  needed  from  the  Set-of-Flag  diagram  to  the  List-of 
Flag  diagram  as  depicted  using  solid  arrows  in  the  diagram  on  the  right  in  Figure  C-24. 


One-Sort  One-Sort 


Figure  C«24.  Example  refinement  of  an  aggregate  object 

In  this  case  the  interpretation  from  specification  One-Sort  in  the  Set  diagram  to  specification 
One-Sort  in  the  List  diagram  is  simply  the  identity  interpretation,  One-Sort  Hd->  One-Sort  ^id-  One-Sort. 
The  interpretation  for  the  Flag  specifications  is  also  the  identity  interpretation.  To  show  that  all  three 
interpretations  are  compatible  there  must  be  interpretation  morphisms  (solid  triple  arrows)  between  the 
three  interpretations.  These  can  sometimes  be  mechanically  inferred  given  the  rest  of  the  diagram 
[SLM98].  Once  all  of  the  solid  arrows  in  Figure  C-24  have  been  established,  the  dashed  arrows  can  be 
mechanically  generated  by  using  colimit  (in  this  case  pushout)  constructions  and  by  composing  various 
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moiphisms.  The  Specware  system  does  not  have  a  syntax  for  representing  diagram  refinement  although 
one  can  interactively  (graphically)  build  a  diagram  refinement  in  the  Specware  environment  and  can 
simulate  a  diagram  refinement  by  using  the  lower  level  diagram  and  colimit  statements. 

As  this  small  example  demonstrates,  it  is  possible  to  construct  a  larger  specification  from  smaller 
component  specifications  and  then  to  combine  the  refinements  of  the  smaller  specification  into  a 
refinement  of  the  larger  specification.  This  example  deliberately  avoided  (glossed  over)  some  of  the 
messier  details  of  the  diagram  refinement  that  can  be  found  in  [SLM98]  and  that  are  taken  to  task  in 
Section  2.5. 

C.4.5  Refining  complex  structure 

The  requirement  specification  for  a  complex  application  may  have  a  great  deal  of  “structure”  as  it 
could  be  recursively  created  using  colimits  and  extensions  of  many  existing  specifications.  For  example  a 
requirement  specification  may  be  constructed  as  a  definitional  extension  of  the  colimit  specification  of  a 
diagram  of  specifications  where  the  specifications  in  the  diagram  also  may  contain  similar  “structure”.  In 
order  to  refine  such  con:q)lex  structure,  refinement  by  definitional  extension  and  refinement  by  diagram 
refinement  should  compose  such  that  refinements  are  rippled  down  the  stmcture  of  the  specification. 

The  two  types  of  refinement  do  compose  as  diagram  refinement  results  in  a  refinement  of  the 
colimit  specification  of  that  diagram,  any  definitional  extension  of  that  colimit  specification  can  have  its 
refinement  mechanically  generated.  Thus  as  long  as  a  specification  is  structured  using  colimits  and 
definitional  extensions,  compatible  individual  refinements  of  the  component  specifications  can  be 
composed  to  form  a  refinement  of  the  aggregate  specification  as  a  whole. 

C.4.6  Appl5dng  structured  refinements 

As  the  refinements  Set=>Bag  and  Bag=>List  indicate,  the  individual  refinements  of  specifications 
may  have  “structure”  as  well,  where  successive  design  decisions  are  made  by  successive  interpretations. 
This  can  be  extended  to  the  diagram  level  where  the  design  decisions  at  the  larger  diagram  level  result  in 
the  need  for  successive  diagram  refinements. 

Successive  diagram  refinements  can  be  composed  because  interpretations  conqjose  and  the  shape 
mappings  compose  successive  diagram  refinements  compose  as  well  [SJ95].  This  can  be  accomplished  by 
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first  composing  file  interpretations  that  make  up  the  successive  diagram  refinements  and  then  performing  a 
single  diagram  refinement,  or  it  can  be  accomplished  by  performing  the  diagram  refinements  individually 
and  then  composing  the  (successive)  interpretations  that  result. 

C5  Code  Generation 

As  described  in  Section  B.2,  one  meaning  of  a  specification  is  the  class  of  models  that  satisiy  the 
specification.  A  more  practical  meaning,  however,  is  the  class  of  programs  in  a  programming  language  that 
are  models  of  the  specification.  The  meaning  of  a  refinement  can  be  defined  in  terms  of  the  delta  between 
the  meanings  associated  with  the  source  and  target  specifications,  i.e.  the  delta  between  the  models 
associated  with  the  source  specification  and  the  models  associated  with  the  target  specification.  However, 
the  goal  of  a  transformation  system  is  to  refine  a  specification  until  it  can  be  translated  directly  to  code.  So 
another  meaning  of  a  refinement  is  the  delta  that  occur  in  the  translations  of  the  source  and  target 
specifications  to  code. 

C.5.1  Models  semantics  vs.  generated  code  semantics 

Unfortunately  not  all  so-called  design  specifications  can  be  translated  directly  to  code,  as  refining 
a  specification  so  that  it  has  a  single  model  is  not  the  same  thing  as  refining  it  so  that  it  can  be  translated  to 
code.  As  an  example.  Figure  C-25  contains  two  different  definitions  of  the  Size  operations.  The  second 
definition  is  arguably  a  refinement  of  the  first  yet  both  definitions  have  the  same  function  as  their  model 
(assuming  the  usual  List  specification  semantics). 

spec  List  is 

op  append:  E,  List  -^List 
op  Size:  List  — >  Nat 

define  Size  by 

ax  Size (Empty (L) )  =  0 

ax  Size (Insert (e, L) )  =  1  +  Size(L) 

vs. 

define  Size  by 

ax  Size (L)  =  if  Is -Empty (L)  then  0 
else  1  +  Size (Tail (L) ) 

end -spec _ 

Figure  C-25.  Constructive  vs.  non-constructive  definitions 
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C.5.2 


Constructive  vs.  non-constructive  definitions 


One  of  the  main  reasons  why  a  specification  could  not  be  translated  to  code  is  that  the  definitions 
of  various  sorts  and  operations  may  not  be  constructive  in  nature  (“what”  is  defined  but  “how”  is  not).  As 
an  example,  only  one  of  the  definitions  in  Figure  C-25  is  constmctive.  The  first  definition  (the  definition 
based  on  the  constmctors  Empty  and  Insert  interestingly  enough)  is  the  non-constructive  definition.  The 
second  definition  (based  on  the  “destmctor”  Tail  and  the  “base  test”  Is-Empty)  is  the  constructive  definition 
as  there  is  an  obvious  translation  to  code  given  the  existence  of  operations  Tail  and  Is-Empty. 

As  another  example,  Figure  C-26  contains  two  equivalent  definitions  for  the  operation  Fermat. 

The  equivalency  of  these  two  definitions  has  only  recently  been  proven  [Wil95].  The  first  definition 
expresses  the  problem  solved  by  the  operation  but  does  not  express  how  (constructively)  to  arrive  at  an 
answer.  A  constructive  (algorithmic)  definition  would  be  searching  for  such  an  answer  for  a  very  long 
time.  However,  because  the  answers  are  now  known,  the  operation  Fermat  can  be  defined  as  shown  in  the 
second  definition  in  Figure  C-26.  The  second  definition  is  also  constructive  and  is  easily  translatable  to 
code;  however,  the  only  indication  as  to  what  problem  is  being  solved  by  the  operation  is  the  user-friendly 
name,  Fermat,  of  the  operation.  These  two  definitions  exemplify  the  difference  between  specifying  what 
and  specifying  how.  The  first  definition  is  easy  to  understand  in  terms  of  what  problem  is  being  solved, 
although  how  to  arrive  at  a  solution  is  not  immediately  apparent.  The  second  definition  is  easy  to  use 
determine  to  an  answer,  although  one  is  imsure  if  it  is  solving  the  correct  problem. 

spec  Fermat  is 

op  Fermat:  Nat  ->  Boolean 

define  Fermat  by 

ax  Fermat  (n)  o  3  x,y,z:Nat  j  x"  -i-  y“  =  z” 

define  Fermat  by 

ax  Fermat (n)  =  if  (n  =  0)  or  (n  >  2)  then  False 

else  True 

end- spec  _ _ 

Figure  C-26.  Example  requirement  specification  for  which  no  code  can  be  generated 

C.5.3  Translation  via  inter-logic  morphism 

Assuming  that  certain  conditions  concerning  the  axioms  are  met  (such  as  all  existentials  have  been 
eliminated  through  design  decisions),  the  final  design  specification  can  be  translated  to  code  via  direct 
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translation  [Lin93,  Loeckx87]  or  via  an  inter-logic  morphism  [SJ95,  Meseguer89]).  The  inter-logic 
morphism  method  used  by  the  Specware  system  is  called  an  entailment  system  morphism  [WSGJ96].  For 
this  approach  to  work,  only  a  “translatable”  subset  of  the  Specware  specification  language  can  be  used  in 
the  final  design  specification,  essentially  conditional  equational  logic,  plus  a  select  set  of  “base” 
specifications  that  have  pre-established  translations  (typically  corresponding  to  built  in  type  and  operations 
of  the  programming  language). 

For  each  implementation  language  that  the  final  design  could  be  translated  to,  there  must  exist  an 
entailment  system  that  describes  the  language  in  its  own  logic  and  syntax.  The  entailment  system  in  the 
implementation  language  enables  statements  in  the  language  to  be  reasoned  about  mechanically.  An 
entailment  system  morphism  is  then  used  to  map  the  entailment  system  of  the  subset  of  the  specification 
language  to  the  entailment  system  of  the  mq)lementation  language.  This  entailment  system  morphism 
enables  correctness  in  the  specification  language  to  be  preserved  in  the  implementation  language.  Given 
that  this  entailment  system  morphism  exists,  the  specification  to  code  transformation  is  acconplished  by 
establishing  a  morphism  (actually  an  interpretation)  between  the  final  requirement  specification  and  a 
program  in  the  implementation  language.  The  definitional  extension  part  of  this  interpretation  between  the 
two  logics  is  the  generated  code.  (A  collection  of  pre-established  base  code  in  the  target  implementation 
language  is  extended  definitionally  so  that  it  implements  the  design  specification  in  the  source  specification 
language.) 

For  any  particular  source  specification  language  and  target  implementation  language  there  may  be 
a  collection  of  additional  requirements  on  the  final  design  specification  in  order  for  the  entailment  system 
morphism  and  inter-logic  interpretation  to  work.  The  Specware  system  requires  colimit  independence, 
colimit  uniqueness,  constructiveness  of  definitions,  axiom  form  and  semantics,  and  sort  constructor 
restrictions  when  going  to  Lisp  and  C  code  [WSGJ96].  While  these  restrictions  are  burdensome,  they  do 
not  apply  to  all  specifications  and  definitions  in  the  refinement  process,  only  the  final  design  specification 
that  is  to  be  mechanically  translated. 
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Appendix  D.  Diagram  Construction 


As  a  motivating  example  for  the  use  of  parameterized  diagrams,  the  data  structure  for  a  Petri  Net 
[Pet77]  is  developed  using  two  different  versions  of  the  diagram  constmction  method  (listing  a  diagram’s 
nodes  and  arcs).  A  Petri  Net  data  stmcture  can  be  specified  as  consisting  of  the  following  collection  of 
smaller  data  structures:  a  set  of  places,  a  set  of  transitions,  a  map  from  places  to  natural  numbers 
representing  the  number  of  Petri  Net  tokens  at  any  given  place,  and  bags  of  input  and  output  arcs  that 
connect  places  to  transitions  and  transitions  to  places.  This  abstract  stmcture  of  a  Petri  Net  is  depicted  in 
Figure  D-1. 


Figure  D-1.  Pictorial  representation  of  the  abstract  data  structure  of  a  Petri  Net 


The  Specware  language  code  [SLM98]  in  Figure  D-2  constmcts  the  diagram  in  Figme  D-1  using 
specifications  and  morphisms  as  the  largest  reusable  objects.  The  specifier  has  to  recreate  the  “fixed” 
portion  of  the  diagram  as  well  as  the  “variable”  portion  of  the  diagram  for  a  number  of  smaller  abstract  data 
type  instantiations  that  are  built  up  into  the  larger  Petri  Net  data  type.  From  the  code  in  Figure  D-2  alone  it 
is  difficult  to  imderstand  what  is  being  constmcted  or  what  specification  one  will  end  up  with  once  the 
colimit  of  the  diagram  is  taken.  Constmcting  such  a  diagram  by  listing  its  nodes  and  arcs  is  not  a  natural 
way  to  express  such  a  complex  data  stmcture.  Neither  is  drawing  such  a  diagram  using  a  graphical  editor 
to  place  the  nodes  and  connect  them  with  arcs.  The  constmction  of  such  large,  monolithic  diagrams  from 
individual  specifications  and  morphisms  is  called  the  diagram  constmction  approach. 
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Diagram  Petri-Net  is 

Nodes  Tl: One -Sort,  T2: One -Sort,  SI: Set,  S2:Set,  Place,  Transition, 
T3: One- Sort,  T4: One-Sort,  PI: Pair, 

T5: One-Sort,  T6: One-Sort,  P2:Pair, 

T7: One- Sort,  T8: One-Sort,  Bl:Bag,  B2:Bag, 

T9: One -Sort,  TO: One -Sort,  Map,  Empty 

Arcs 


T1  -> 

Place: 

{X  -> 

Place} 

T1  -> 

SI: 

{X  -> 

E} 

T2  -> 

Transition: 

{X  -> 

Transition} 

T2  -> 

S2: 

{X  -> 

E} 

T3  -> 

Place 

{X  -> 

Place} 

T3  -> 

PI: 

{X  -> 

A} 

T4  -> 

Transition: 

{X  -> 

Transition} 

T4  -> 

PI: 

{X  -> 

B} 

T5  -> 

Transition: 

{X  -> 

Transition} 

T5  -> 

P2: 

{X  -> 

A} 

T6  -> 

Place 

{X  -> 

Place} 

T6  -> 

P2: 

{X  -> 

B} 

T7  -> 

Bl: 

{X  -> 

E} 

T7  -> 

PI: 

{X  -> 

Pair} 

T8  -> 

B2  : 

{X  -> 

E} 

T8  -> 

P2: 

{X  -> 

Pair} 

T9  -> 

Map; 

{X  -> 

Dorn} 

T9  -> 

Place 

{X  -> 

Place} 

TO  -> 

Map: 

{X  -> 

Cod} 

TO  -> 

Empty : 

{X  -> 

Empty . Nat } 

end- diagram 

Figure  D-2.  Diagram  construction  approach  for  developing  a  Petri  Net  specification 


An  alternative  diagram  construction  method  breaks  the  problem  into  smaller  pieces,  each  of  which 
performs  part  of  the  necessary  constmction,  that  build  upon  each  other  to  form  the  overall  Petri  Net 
specification.  An  example  of  this  piecemeal  diagram  construction  approach  is  depicted  in  Figure  D-3 
where  the  Petri  Net  specification  is  developed  in  a  sequence  of  steps. 

The  upper  left  diagram  (and  colimit)  in  Figure  D-3  creates  a  diagram  (and  specification)  that 
contains  sets  of  places  and  sets  of  transitions.  The  upper  right  diagram  (and  colimit)  in  Figure  D-3  creates 
a  diagram  (and  specification)  that  has  input  and  output  arcs  represented  by  the  pairs  <place,  transition>  and 
<transition,  place>,  respectively,  by  adding  to  the  previously  constructed  specification.  The  lower  left 
diagram  (and  associated  specification)  adds  bags  of  input  and  output  arcs.  The  final  diagram  (and 
specification)  creates  the  data  stracture  of  a  Map  from  Places  to  Nats  that  is  used  to  associate  a  number  of 
tokens  with  each  place  in  the  Petri  Net  data  structure.  Thus  the  specification  Petri-Nets  is  isomorphic  to 
the  specification  that  one  gets  when  taking  the  colimit  of  the  diagram  developed  in  Figure  D-2,  but  it  was 
arrived  at  piecemeal.  The  overall  diagram  as  depicted  in  Figure  D-1  does  not  exist  in  the  piecemeal 
approach,  as  in  each  step  it  is  the  colimit  specification  that  is  being  extended  and  not  the  diagram. 
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PIM- 


Figure  D-3.  Petri  Net  specification  using  four  separate  diagrams 


The  use  of  intermediate  specifications  and  diagrams  introduces  dependencies  among  the 
specifications  that  are  not  present  in  the  diagram  construction  approach  used  in  Figure  D-2.  For  example, 
in  Figure  D-3  and  Figure  D-4  it  appears  that  one  must  create  the  diagram  representations  for  a  set  of  places 
prior  to  creating  the  diagram  representations  for  a  map  from  places  to  natural  numbers,  which  is  not  the 
case.  The  order  and  content  of  the  specifications  Petri  Netl  through  Petri  Net4  in  Figure  D-4  are  somewhat 
arbitrary,  as  the  piecemeal  construction  could  be  accomplished  in  a  number  of  different  ways.  The  use  of 
the  piecemeal  construction  constitutes  a  false  economy,  as  certain  kinds  restructuring  refinements  are  no 
longer  possible  based  on  the  false  dependencies  induced  by  the  use  of  intermediate  colimit  specifications. 

While  the  construction  depicted  in  Figure  D-3  appears  easier  to  understand  from  a  diagrammatic 
standpoint,  the  code  for  it  is  longer  than  for  the  all-at-once  diagram  construction  approach  and  the  code  is 
still  very  complicated,  as  can  be  seen  in  Figure  D-4. 
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Figure  D>4.  Piecemeal  diagram  construction  approach  for  developing  a  Petri  Net  specification 


The  language  construct  for  creating  and  instantiating  parameterized  diagrams  that  is  developed  in 
Chapter  5  enables  the  specifier  to  reuse,  parameterize  and  instantiate  diagrams  which  enables  a  specifier  to 
work  at  a  higher  level  of  abstraction. 
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Appendix  E.  Parameterized  Specifications 

This  appendix  presents  examples  of  category-theory-based  parameterization  and  A.-style 
parameterization  including  single  parameterization,  multiple  parameterization,  and  parameterization  by  a 
diagram  as  well  as  nested  and  recursive  instantiation, 

E,  1  Category  theory  style  parameterization 

In  this  section  the  various  forms  of  category-theory-based  parameterization  are  described  in  terms 
of  parameterized  diagrams  (Section  4.2). 

E.  1 . 1  Parameterization  by  a  single  parameter 

The  most  basic  form  of  category-theory-based  parameterization  uses  only  a  single  parameter.  In 
single-parameterization,  a  parameterized  specification  is  a  moiphism  [BG77,  EL78,  Gan83,  and  EM85] 
between  a  formal  parameter  specification  and  a  body  specification,  specpomiai^specBody  The  parameterized 
specification  is  instantiated  by  developing  a  morphism  from  the  formal  parameter  specification  to  an  actual 
parameter  specification,  specpormai-^spec Actual-  This  morphism  accomplishes  two  things.  It  ensures  that  the 
actual  parameter  specification  has  at  least  as  much  structure  and  properties  as  the  formal  parameter 
specification.  Second,  together  with  the  morphism  to  the  body  specification,  it  forms  the  diagram 
specBody*^-  specForniai-^spec Actual-  The  colimit  object  of  that  Spec  diagram  is  a  specification. 

Single-parameterization  is  used  in  the  specification  languages  Clear  [BG77,  BG80]  and  ACT  ONE 
[EM85,  Cla89].  Different  specification  languages  and  researchers  have  placed  (or  proposed)  different 
constraints  on  parameterized  specifications  for  a  variety  of  reasons.  The  most  common  constraint  is  that 
the  morphism  between  the  formal  parameter  and  the  body  be  a  conservative  extension  (also  called  a 
persistent  enrichment  or  theory  embedding  in  the  literature).  The  reasons  for  tiiis  are  discussed  in  Section 
C.  1 .4.  Because  diis  type  of  morphism  is  conserved  xmder  pushout,  the  morphism  between  actual 
parameter  and  instantiated  body  will  also  be  a  conservative  extension. 

An  example  of  a  single-parameterization  and  instantiation  is  depicted  in  Figure  E-1  using  the 
Specware  language  [SJ95,  SLM98].  The  bolded  portion  of  the  diagram  is  the  “parameterized 
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specification”.  Specification  One-Sort  is  the  formal  parameter  and  specification  Set  is  the  parameterized 
body.  The  morphism  from  specification  One-Sort  to  specification  Set  links  the  formal  parameter 
specification  to  the  body  specification  and  ensures  that  the  formal  parameter  theory  is  embedded  in  the 
body  flieory.  The  specification  Flag  is  the  actual  parameter  to  the  parameterized  specification.  The 
morphism  from  the  formal  parameter  specification  One-Sort  to  the  actual  parameter  specification  Flag 
ensures  that  the  actual  parameter  meets  the  requirements  of  the  formal  parameter  and  represents  “parameter 
passing”.  The  pushout  object  of  the  resulting  diagram,  specification  Set-of-Flag,  is  the  instantiated 
parameterized  specification.  Using  a  different  actual  parameter  and  performing  a  pushout  results  in  a 
different  instantiated  Set  specification.  Figure  E-2  depicts  a  “parameterized  specification”  that  has  not  been 
instantiated. 


Figure  £-1.  Instantiation  by  colimit 


Using  a  morphism  between  a  formal  parameter  specification  and  a  body  specification  is  too 
limiting  a  mechanism  to  capture  the  richness  needed  to  reflect  the  types  of  parameterization  needed  in  a 
formal  software-engineering  environment.  The  notion  of  a  single  specification  as  a  formal  parameter 
forces  all  “variable”  parts  of  a  parameterization  to  be  described  within  a  single  formal  parameter 
specification  and  thus  forces  all  actual  parameters  to  be  represented  by  a  single  specification.  Even  simple 
abstract  data  types  have  “multiple”  parameters.  (An  Array  has  an  index  type  and  an  element  type,  and  a 
map  has  a  domain  type  and  a  codomain  type.)  Maps  and  Arrays  and  similar  abstract  data  types  could  only 
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be  specified  using  the  limiting  single-parameterization  mechanism  by  joining  the  (possibly)  completely 
independent  type  parameters  into  a  single  formal  (and  actual)  parameter  specification. 


{X  ?} 


{X  E) 

_ I _ 

Spec  Bag  is 
sort  Bag ,  E 
op  Empty: 
op  Insert: 
op  In: 

Constructors  {Empty,  Insert)  construct  Bag 

Forall  b,bl,b2:Bag,  e,el,e2:E 
Ax  not (In (e, Empty) ) 

Ax  in (el, Insert (e2,b) )  =»  ((el=e2)  v  In(el,b)) 

Ax  Insert  {e,bl)  =  Insert  (e,b2)  ^  bl=b2 
Ax  Insert (el, Insert  (e2,b) )  =  Insert (e2.  Insert (el, b) ) 
end- spec 


Figure  E-2.  Example  of  single-parameterization 


->  Bag 
E,  Bag  ->  Bag 
E,  Bag  ->  Boolean 


Spec  One -sort 
sort  X 
end- spec 


E.  1 .2  Parameterization  by  multiple  parameters 

In  [Hax89],  a  multi-parameterized  specification  is  defined  to  be  a  single  body  specification  with 
multiple  parameter  specifications  where  the  parameters  have  no  relationship  with  each  other.  More 
formally,  a  parameterization  of  multiplicity  n  consists  of  n  parameter  specifications,  Pj,  j  =  l..n,  a  body 
specification,  S,  and  n  specification  morphisms,  Oj:Pj-^S.  Instantiation  involves  creating  n  morphisms  to  n 
actual  parameter  specifications,  pj:  Pj  ->  Aj,  j  =  l..n,  and  taking  the  colimit  of  the  resulting  diagram.  The 
research  presented  in  [Hax89]  did  not  define  a  convenient  syntax  for  creating  or  instantiating  multi- 
parameterized  specifications.  A  parameterized  specification  was  formally  represented  as  a  collection  of 
morphisms  that  have  a  common  codomain  (a  cocone).  Each  cocone  morphism  firom  one  of  the  parameter 
specifications  to  the  body  specification  must  be  a  conservative  extension  morphism 

The  capabilities  of  the  single-parameterization  and  multi-parameterization  theories  are  graphically 
depicted  in  Figure  E-3  using  the  parameterized  diagram  notation  developed  in  Section  4.2.3.  While  single- 
parameterization  enables  parameterized  objects  to  be  of  the  shape  of  Figure  E-3(a),  multi-parameterization 
allows  parameterized  objects  to  be  of  the  shape  of  Figure  E-3(b).  Single-parameterization  is  just  a  special 
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case  of  multi-parameterization.  An  example  of  multi-parameterization  is  depicted  in  Figure  E-4,  using  the 


Specware  language. 


(a)  Parameterization  by  pushout  (b)  Parameterization  by  multiple 

formal  parameters 

Figure  E-3.  Single-parameterization  compared  with  multi-parameterization 


Figure  E-4.  Example  of  multi-parameterization 


The  OBJ3  specification  language  [GWM92]  has  a  sophisticated  parameterization  mechanism  that 
can  create  and  instantiate  multi-parameterized  specifications.  As  an  example,  the  OBJ  code  in  Figure  E-5 
consists  of  (using  OBJ  terminology)  a  theory  ONE-SORT,  an  object  BITS,  a  view  OS-BITS  of  how  the 
object  BITS  satisfies  the  theory  ONE-SORT,  a  parameterized  object,  and  the  instantiation  PAIR-of-BITS. 
In  the  example,  two  copies  of  the  “specification”  ONE-SORT  parameterize  “specification”  PAIR. 
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th  ONE- SORT  is 
sort  X  . 
endth 


obj  BITS  is 

sorts  Bit  Bits  . 
subsorts  Bit  <  Bits  . 
ops  0  1  :  ->  Bit  . 

op _ :  Bit  Bits  ->  Bits  . 

endo 


view  OS-BITS 

from  ONE-SORT  to  BITS  is 
sort  X  to  Bits  . 
endv 


obj  PAIR [PI  P2::  ONE-SORT]  is 
sort  pair 

op  <<_;_>>  :  X.Pl  X.P2  ->  pair, 
op  1*_  :  pair  ->  X.Pl 

op  2*_  :  pair  ->  X.P2 

var  el  :  X.Pl  . 

var  e2  :  X.P2  . 

eq  1*  <<el  ;  e2  >>  =  el  . 
eq  2*  <<el  ;  e2  >>  =  e2  . 
endo 


make  PAIR-of-BITS  is 

BITS [OS-BITS,  OS-BITS] 
endm 


Figure  £-5.  OBJ  multi-parameterization  example 


Although  the  code  in  Figure  E-5  appears  to  be  a  syntactic  sugar  version  of  A,-style 
parameterization,  it  is  actually  a  (syntactic  sugar)  version  of  category-theory-based  parameterization  as  the 
underlying  parameterization  mechanism  involves  the  use  of  category  theory  and  not  functions  and  function 
composition. 

The  OBJ  code  in  is  depicted  as  a  diagram  of  specifications  and  moiphisms  in  Figure  E-6  in  order 
to  demonstrate  the  underlying  category  theory  semantics.  The  OBJ  theory  ONE-SORT  and  object  BITS 
are  essentially  specifications  with  different  underlying  model  theories.  The  view  OS-BITS  is  essentially 
the  morphism  ONE-SORT-^BITS.  The  parameterized  object  PAIR  can  be  thought  of  as  bodi  a 
specification  and  as  a  diagram  of  specifications  and  morphisms.  The  diagram  PAIR  is 
ONE-SORT->PAIR<-ONE-SORT  where  both  ONE-SORT  diagram  nodes  have  inclusion  moiphisms  to 
the  specification  PAIR.  Finally,  specification  PAIR-of-BITS  is  the  colimit  of  the  diagram 
BITS4-'0NE-S0RT->PAIR4-0NE-S0RT-»BITS  that  was  formed  by  “instantiating”  the  PAIR  diagram 
(twice)  with  the  OS-BITS  morphism. 
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OBJ  has  executable  semantics  and  is  not  used  for  refinement.  Because  of  the  execution  semantics 


there  is  no  need  for  multiple  copies  of  a  specification  in  the  resulting  colimit  specification.  Thus,  for 


example,  the  two  BITS  specifications  in  Figure  E-6  would  be  combined  so  that  there  is  only  one  copy  in 


the  resulting  colimit  specification. 


Figure  £>6.  Category  theory  semantics  of  OBJ  multi-parameterization 


E.  1 .3  Parameterization  by  a  diagram  of  parameters 

The  formal  parameter  specifications  in  multi-parameterization  are  con^letely  independent  of  each 
other.  Parameterization  by  a  diagram  of  parameters  enables  the  formal  and  actual  parameters  to  be 
structured,  i.e.  related  to  each  other.  In  [Dim98],  parameterization  consists  of  a  body  S,  a  diagram  P,  and  a 
cocone  P-^S.  Parameterization  by  a  diagram  of  formal  parameters  can  be  viewed  as  a  generalization  of 
multi-parameterization  where  the  formal  parameters  (and  actual  parameters)  are  related  to  each  other.  As 
with  multi  parameterization,  there  must  be  a  conservative  extension  morphism  from  each  specification  in 
the  formal  parameter  diagram  to  the  body  specification.  There  must  also  be  a  conservative  extension 
morphism  from  the  colimit  of  the  parameterizing  diagram  P  to  the  body  specification. 

In  order  to  instantiate  the  parameterization  by  a  diagram  of  parameters,  there  must  exist  a  family 
of  compatible  morphisms  to  the  instantiating  specifications  as  depicted  in  Figure  E-7,  There  does  not  exist 
a  high-level  specification  language  syntax  for  creating  and  instantiating  specifications  that  are 
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parameterized  by  diagrams  as  depicted  in  Figure  E-7.  An  example  of  parameterization  by  a  diagram  of 
parameters  is  depicted  in  Figure  E-8  using  the  Specware  language. 


Parameterization  by  a  diagram 
(multiple  related  formal  parameters) 
and  a  cocone  of  morphisms 


Figure  £-7.  Parameterization  by  a  diagram  of  parameters 


spec  List  is 
sort  List,  E 

op  Empty:  ->  List 

op  Append:  E,  List  ->  List 
op  In:  E,  List  ->  Boolean 

Constructors  {Empty,  Append}  Construct  List 
Forall  s,sl,s2:List,  e,el,e2:E 
Not (in (e, Empty) ) 

Not (Empty  =  Append (e,s}) 
in (el, Append (e2, s) )  =>  (el=e2  v  in(el,s)) 
(insert (el, si)  =  Insert (e2, s2) )  o 
(el=e2  A  sl=s2} 

end- spec 


Spec  Total -order 
sort  X 

op  TO:  X,  X  ->  Boolean 
Forall  a,b,c:X 

Ax  TO(a,b)  XOR  TO{b,a)  XOR  a=b 
Ax  Not (TO (a, a) ) 

Ax  TO(a,b)  AND  TO(b,c)  =>  T0(a,c) 
end- spec 


Spec  Sort  is 
sort  List,  E 

op  Empty;  ->  List 

op  Append:  E,  List  ->  List 
op  In:  E,  List  ->  Boolean 

op  TO:  E,  E  ->  Boolean 

op  IsOrdered;  List  ->  Boolean 
op  count:  E,  List  ->  Nat 
op  permutation;  List,  List  ->  Boolean 
op  sort:  List  ->  List 

Constructors  {Empty,  Append}  Construct  List 
Forall  s,sl,s2;List,  e,el,e2;E 
Ax  Not (in (e, Empty) ) 

Ax  Not (Empty  =  Append (e,s)) 

Ax  in (el, Append (e2, s) )  (el»e2  v  in(el,s)) 

Ax  (insert (el, si)  =  Insert (e2, s2) )  o  (el=e2  a  b1=s2) 

Ax  T0(el,e2)  XOR  T0(e2,el)  XOR  el=e2 
Ax  Not (TO (e, e) ) 

Ax  TO(e,el)  AND  T0(el,e2)  =>  TO(e,e2) 


Ax  IsOrdered (Empty) 

Ax  IsOrdered (Append (e, s) }  => 
in  (el,  s)  =>  It  (e,  el) ) 
Ax  Count ( e ,  Empty)  =  0 
Ax  Count (el.  Append (e2, s) )  = 


(IsOrdered (s)  and 


if  el=e2  then  1  +  Count (el, s) 
else  Count (el, s) 

Ax  Permutation(sl,s2)  o  Count (e, si)  =  Count (e,s2) 

Ax  Sort(sl)=s2  o  Perrautation(sl, s2)  and  IsOrdered (s2) 
end- spec 


Figure  £-8.  Example  of  parameterization  by  a  diagram  of  parameters 
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E.1.4 


Nested  parameter  passing  and  recursive  parameter  passing 
Nested  parameter  passing  involves  passing  a  parameterized  object  as  an  actual  parameter,  i.e.  the 
body  of  one  parameter  object  is  passed  as  the  actual  parameter  to  another  parameterized  object.  Recursive 
parameter  passing  involves  the  formal  parameters  of  two  (or  more)  parameterized  objects  being  instantiated 
to  each  other’s  body  [Hax89].  Most  if  not  all  specification  languages  can  handle  nested  parameter  passing 
as  depicted  in  Figure  E-9  diagram  (a),  but  not  recursive  parameter  passing  as  depicted  in  Figure  E-9 


diagram  (b). 


(a)  Nested  parameter  passing  (b)  Recursive  parameter  passing 

(for  example  a  Set  of  Sequences  of  integers)  (for  example  Coroutines  or  a  mutually  recursive  data  structure) 

Figure  E-9.  Nested  parameter  passing  compared  with  recursive  parameter  passing 


E,2  Lambda-style  parameterization 

The  syntax  “A.  xtspecparam  |  speceody”  identifies  x  as  the  formal  parameter  name,  specparam 
as  the  formal  parameter  requirements  and  specBody  as  the  parameterized  specification  body.  Both  the 
requirement  and  body  specifications  are  built  using  specification  building  operations  that  may  reference  the 
specification-valued  variable  x.  Passing  a  parameter  (actual  specification)  to  the  A,-expression  binds  the 
variable  x  to  the  actual  specification  parameter.  (Essentially  establishing  a  morphism  from  the  actual 
parameter  to  the  formal  parameter.)  Thus  X  xispecparam  I  specBody  is  a  function  from  specifications  meeting 
the  formal  parameter  requirements  to  specifications  produced  by  the  specification  building  operations  of 
specBody  A,-style  parameterization  is  used  in  the  specification  languages  ASL  [SW83,  Wir86],  COLD 
[Jon89,  FJ92],  and  Spectrum  [BFG93]. 

An  example  of  X-style  parameterization  is  depicted  in  Figure  E-10.  In  this  exan^le  the  actual 
specification  that  is  passed  as  a  parameter  is  enriched  with  additional  sorts,  operations  and  axioms. 
Enrich  is  a  function  that  accepts  a  specification  valued  parameter  and  returns  a  specification.  In  general 
any  specification  transformation  operation  could  be  applied  to  the  actual  parameter  specifications  such  as 
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“union”  that  combines  specifications  and  “derive”  that  allows  operations  and  sorts  to  be  hidden.  This  style 
of  parameterization  is  not  discussed  further  as  the  language  and  syntax  of  ^-style  parameterization  does  not 
fit  with  Ae  type  of  categorical  constructs  used  in  this  dissertation. 


VAL  =  Enrich  Bool  by 
Sorts  val 

Ops  eq:  val,  val  ->  bool 
Forall  x,y:val 
Ax  eq(x,x) 

Ax  Not  (x=y)  =>  Not(eq(x,y)) 

SET  =  XK:  val.  Enrich  X  by 
Sorts  set 
Ops  Empty:  ->  set 

Insert:  set,  val  ->  set 
In:  set,  val  ->  bool 
Forall  s:set,  x,y:val 

Ax  Insert (Insert (s,x) ,y)  =  Insert (Insert (s,y) ,x) 

Ax  Insert (Insert (s,x) ,x)  =  Insert (s,x) 

Ax  Not (In(empty,x) ) 

_ Ax  In(x(insert (s,y) )  =  In(s,x)  OR  eq(x,y)  _ 

Figure  E-10.  X-style  parameterization 

While  the  “body”  in  A,-style  parameterization  can  be  more  then  a  single  specification  (it  can  be  a 
collection  of  operations,  the  result  of  instantiation  is  still  a  specification.  This  makes  ^-style 
parameterization  unsuitable  for  constructing  large  structured  specifications. 


258 


Appendix  F.  Code  for  Example  Diagram  Interpretations 


diagram  Bag -of -Pairs [A, B]  is 
import  Pair[],  Bag[] 
instantiate 

Pair [A,  Bag[B]] 
end -diagram 

diagram  Map-to-Bag  is 

Nodes  Pl:One-Sort,  P2:0ne-Sort,  A:One-Sort,  B:One-Sort,  Cod:One-Sort , 
Map,  Bag,  Pair 
Arcs  PI  ->  A  :  { } 

P2  ->  B  :  {} 

A  ->  Pair:  {X  ->  a}, 

A  ->  Map:  {X  ->  dom} , 

B  ->  Pair:  {X  ->  b}, 

B  ->  Bag:  {X  ->  E}, 

Cod  ->  Map:  {X  ->  cod}, 

Cod  ->  Bag:  {x  ->  bag} 
end- diagram 

spec  BagOf Pairs -as -MapToBag  is 
import  colimit  of  Map-to-Bag 
op  Empty:  ->  Map 
op  Insert:  Pair,  Map  ->  Map 
op  In:  Pair,  Map  ->  Boolean 

Constructors  {Empty,  Insert}  constiruct  Map 
Forall  a:A,  b:B,  m:Map 
Define  Empty  by 

Ax  Empty  =  Constant -Map (Bag .Empty) 

Define  Insert  by 

Ax  Insert {<a,b>,  m)  =  Modify (m, a, Bag . Insert (b, apply (m, a) ) ) 

Define  In  by 

Ax  In(<a,b>,m)  =  Bag. In (b, Apply (m, a) ) 

Define  Count  by 

Ax  Count  (<a,b>,m)  =  Bag. Count  (b, Apply  (m, a) ) 
end- spec 

diagram  BagOf Pairs -as -MapToBag  is 

nodes  A:One-Sort,  B:One-sort,  Body : BagOf Pairs -as -MapToBag 
arcs  A  ->  Body:  {x->  map. dom} 

B  ->  Body:  (X  ->  Bag.E} 

End- diagram 

dMorphism  BP-to-BPasMB:  BagofPairs  ->  BagOf Pairs -as -MapToBag  is 
PI  ->  A:  {} 

P2  ->  B:  {} 

Bag. One-Sort  ->  bagOfPairs -as -MapToBag:  {X->Pair} 

Pair  ->  bagOfPairs-as-MapToBag:  {} 

Bag  ->  bagOfPairs-as-MapToBag:  (Bag  ->  Map} 

dinterpretation  BagOfPair-to-MapToBag :  BagOfpairs  =>  MapToBag  is 
mediator  BagOf Pairs -as -MapToBag 
dom-to-med  BP-to-BPasMB 
cod-to-med  A  ->  A:  {} 

B  ->  B:  {} 

Pair  ->  BagOf Pairs-as-MapToBag:  colimit-extension-morphism 
_ Etc.  _ _ _ 

BagOfPairs-a$-MapToBag  interpretation  code 
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Spec  Total -order  is 
sort  X 

op  TO:  X,  X  ->  Boolean 
Forall  a,b,c:X 

Ax  TO(a,b)  XOR  TO{b,a)  XOR  a=b 
Ax  Not (TO (a, a) ) 

Ax  TO{a,b)  AND  TO(b,c)  =>  TO{a,c) 
end- spec 

diagram  Set-TO  is 
import  Set[] 
nodes  TO 
instantiate 
Set  [To.x] 

End-diagram 

spec  triple  is 

sort  triple,  A,  B,  C 
op  make -triple:  A,B,C  ->  triple 
op  Project -A:  triple  ->  A 
op  Project -B:  triple  ->  B 
op  Project -C:  triple  ->  C 
constructors  { make -triple } 

construct  triple 

Forall  a:A,  b:B 

ax  project-A (make-triple (a, b,c) )  =  a 
ax  project-B (make-triple (a, b, c) )  =  b 
ax  project-C (make-triple (a, b, c) )  =  c 
end- spec 

diagram  triple  [A,B,C]  is 
nodes  triple, 

Pl:One-Sort,  P2 :One-Sort,  P3 :One-Sort 
arcs  Pl->triple:  {X->  A}, 

P2->triple:  {X->  B}, 

P3->triple:  {X->  C}, 

Pl->?:  {X->  a}, 

P2->?:  {x->  B} 

P3->?:  {x->  C} 

end- diagram 


spec  Tree -structure  is 

import  colimit  diagram  is 

import  triple  []  ,  coproduct  [] 

nodes  nil,  TO 

instantiate 

coproduct [nil, triple] 
triple [cop,  TO.X,  cop] 
end-diagram 

end- spec 
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spec  Tree  is 
sort  Tree,E 

sort -axiom  Tree=cop 
sort -axiom  E  =  X 
op  Empty:  ->  Tree 
op  Add:  E,  Tree  ->  Tree 

op  In:  E,  Tree  ->  Boolean 

op  Is -Empty:  Tree  ->  Boolean 
constructors  {Empty,  Insert}  construct  Tree 

Forall  t:Tree,  e:E 
define  Empty  by 

ax  Empty  =  embed -A (nil) 
define  Is -Empty  by 

ax  Is -Empty (t)  =  (t  =  empty) 
define  Add  by 

ax  Add(e,t)  =  if  Is-Empty(t) 

then  make-triple (nil, e, nil) 
else  if  TO (e, Project-B (t) ) 

then  make-triple (Add (e, Project-A(t) ) ,  project-B (t) ,  project-C (t) ) 
else  make-triple (Project-A(t) ,  project-B (t) ,  Add(e, project-C (t) ) ) 
define  In  by 

ax  In(e,t)  =  If  Is-Empty(t) 
then  FALSE 

else  if  e  =  Project-B (t) 
then  TRUE 

else  if  TO (e, Project-B  (t) ) 

then  In (e, Project-A(t) ) 
else  In (e, Project-C (t) ) 

end- spec 

spec  SetAsTree  is 
import  Tree 
sort  Set 

sort-axiom  Set  =  Tree 
op  Insert 
Forall  s:Set,  e:E 
define  insert  by 

ax  Insert (e,t)  =  if  in(e,t)  then  t 
else  Add (e, t) 

end -spec 

diagram  Tree[E,  TO]  is 
nodes  Tree,  TO 
arcs  TO->Tree:  {X->E} 

T0->?:  {X->E,  TO->TO} 

end -diagram 

diagram  SetAsTree  is 

nodes  SetAsTree,  P:TO,  I:TO 
arcs  P->SetAsTree :  {X->e} 

P->I:  {  } 

end-diagram _ _ _ 

Set-TO-as-Tree  H 
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dinterpretation  Set-TO-to-Tree :Set-TO  ->  Treed 
mediator  SetAsTree 
dom-to-med  One-Sort->P. TO :  {}, 

TO->I.TO:  {}, 

Set->  SetAsTree:  {} 
cod-to-med  TO->TO:{}, 

Tree“>Tree :  import -morphism 

Set-TO-as-Tree  HI 
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